# Test traffic and read-only access

How to run test journeys on a production site without polluting the numbers under investigation, and how to read each system without being able to change it. Facts were checked on 2026-10-17, and the review fixes on 2026-10-20; re-check anything marked "verify live".

## Test traffic

The investigation runs real journeys on the production site. Each one is also a data point in the reports being compared, so it has to be labelled and kept out of every comparison.

- Test identities. A signup or lead journey cannot be repeated with one account, so define a pattern, for example `qa-signup-NN@example.com`, where `NN` is the run number, with a backend test flag set on creation. Create a fresh identity for each run, log which run used which identity, and exclude the flag from the independent count and from the analytics count, on both sides of the ratio, for the baseline and the incident. A proof of 3 failing runs, 3 comparison runs and a retest needs at least 7 identities.
- Debug mode. Run journeys in GTM Preview (Tag Assistant adds a URL parameter that turns on GA4 debug mode) or with `debug_mode: true` on the test events only. They then show in DebugView.
- Developer traffic filter. Before the first test, read Admin, Data filters.
  - Active: debug-mode events are removed from reports and from BigQuery. Use DebugView to see them.
  - Testing, Inactive or missing: test events reach reports. Log each test event's time, journey and test identity in the record so they can be subtracted.
  - Never create, activate or change a filter for the test. It is an admin change, and an active filter's effect is permanent.
- Click IDs. Use only Google's test value `TeSter-123`, with that exact case. Never use a real `gclid`, `gbraid` or `wbraid` copied from a live click.
- Ad links. Trace the final URL with the account's tracking template or final URL suffix applied. Never request the ad-click redirect URL; that records a click against a live campaign. If the tracking template starts with a third-party host (an agency or bid-tool click tracker), trace from the hop after it, or use that vendor's test mode, and record that the first hop was not requested.
- Email links. Take them from a seed-list test send. A real recipient's tracked link is tied to that person, and requesting it records a click for them.
- Ad platform conversion tags. GTM Preview does not stop outgoing tags from reaching live destinations. When the ad platform is not the layer under test, block its conversion hosts in the test browser (DevTools network request blocking) and note it in the evidence. When it is the layer under test, use the platform's own test or diagnostics tooling where it exists.
- Meta test events. Meta says events sent with `test_event_code` are not dropped: they flow into Events Manager and are used for targeting and ads measurement. Treat a Test Events run as a real event and log it.
- Purchases and payments. Never complete a real purchase or create a real customer record outside the flagged test identities. If the journey needs a payment, use the business's test or sandbox route, and say in the record which layers that route shares with production.

## Read-only access

- GA4: Google's GA4 MCP server (Experimental, local, `analytics.readonly`), with `run_report` and `run_realtime_report`.
  - Property change history needs the Editor role, and Google's help page describes filters on it but no export. If the agent's account is Viewer, ask a person with Editor access for a filtered screenshot, or a copy of the entries, for the window.
  - The Admin API's `searchChangeHistoryEvents` needs the `analytics.edit` scope, so it falls outside the read-only rule.
- GTM:
  - Google ships no Tag Manager MCP server.
  - Read through a Google account that holds only Read permission on the container, or a token scoped to `tagmanager.readonly`. The GTM API v2 then serves `versions:live`, `workspaces.list` and `getStatus`, and refuses writes.
  - Stape's open-source GTM MCP server requests the `tagmanager.publish`, `tagmanager.edit.containers`, `tagmanager.delete.containers`, `tagmanager.edit.containerversions`, `tagmanager.manage.users` and `tagmanager.manage.accounts` scopes and has no read-only mode. Its tools are registered one per resource, and `gtm_version` serves get and live alongside publish, remove and update, so filtering tools through `createGtmMcpServer`'s `tools` option cannot make it read-only. If you use it, authorise it with the Read-only account; a prompt that says "ask before publishing" is not a control.
- BigQuery: the BigQuery remote MCP server's `execute_sql_readonly`. Block `execute_sql` with an IAM deny policy so the credential cannot write.
- Google Ads: Google's Google Ads MCP server for click and conversion counts and conversion action settings.
  - Its GAQL tool is `search` in the "search" category. With the bundled `tools_config.yaml`, clients list it as `search_search`; the prefix follows that file, so search the tool list for "search" rather than an exact name.
  - Use the Conversions (by conv. time) columns (`metrics.conversions_by_conversion_date`) when lining up with GA4 or the backend.
- Meta: Events Manager (Overview, the event's Event Deduplication tab, Test Events), read by a person with access to the dataset.
- Tagging-server logs: for server containers on Cloud Run, the Cloud Logging remote MCP server (`logging.googleapis.com/mcp`) with `list_log_entries`, under a role that can only read logs. For hosted providers, their dashboard and logs.
- Docs: Google's Developer Knowledge MCP server (`developerknowledge.googleapis.com/mcp`) searches developers.google.com and docs.cloud.google.com. Help-centre pages on support.google.com are not in its corpus; open them directly.