Standing service tracking-monitor-for-breakage-monthly · revised 11 October 2026
Standing service
Keep your key tracking events working, with scheduled tests and a monthly report
We run your named test events on the live site on an agreed schedule and tell you with evidence when one stops firing or changes.
This starts a conversation by email. Nothing is charged, and nothing is checked, until we have agreed scope and terms with you in writing.
The responsibility you hand over
Tracking breaks quietly. A theme update removes a data layer push, a plugin changes a form, a tag edit disables a trigger, and the report just shows a smaller number. Nobody looks until a decision is made on the wrong figure.
Who it’s for: A shop owner, marketer or agency whose enquiry and purchase tracking has broken silently before and who wants to hear about it early.
Usually starts when: Site updates, theme changes or tag edits keep breaking an event, and the break is only noticed weeks later in a report.
The result: Each month you receive a written record of every named test event, run on the live site, showing whether it fired once with its agreed parameters, the list of scheduled runs actually performed, evidence, and a repair note for any event that did not pass.
What stays true, and what we do about it
No response-time guarantee is published for this new service. A target is agreed in writing before it starts, set to what a service at this stage can actually keep.
The cadence, day and time of the scheduled run are agreed in writing before the service starts. A more frequent cadence, such as weekly, is offered only after the first month has shown that we can keep it. At launch the service is not staffed round the clock and does not offer out-of-hours cover.
What must remain true
- Each named test event is run on the live site on the agreed schedule, and its result is written down with DebugView evidence
- Key event counts are compared with the previous month, and any fall to zero or sharp change that we can see is reported with the evidence we hold
What we watch
- The scheduled test run of the named events in a debug-enabled browser, read in DebugView
- Key event counts in GA4 reports, read through a Viewer role
- The Tag Manager version history, read-only, for changes since the last run
- For a shop, the month's order count that you send us
When something happens
Scroll the table sideways to read it all.
| When | What we do |
|---|---|
| A named test event does not appear, appears twice, or loses an agreed parameter in a scheduled run. | We repeat the run, check the container history for a change, and send you the evidence with a repair note. Priced as: One GA4 key event recording |
| For a shop, the month's GA4 purchase count differs from the order count you send us by more than the margin we agree with you in writing. | We place a test order where the route allows, and report whether duplicates or missing events explain it. Priced as: One order, one GA4 purchase |
| A month ends. | We send the written record: each event's result, count comparison and any open repair. |
We do on our own
- Run the named test events on the live site with test values
- Read DebugView, reports and container history through the read-only roles
- Write a repair note naming the likely cause and the matching one-off job
We ask you first
- Making any change in your accounts: we hold read-only access, so every change is a one-off job that you approve and give the access it needs
- Adding a new test event or removing one
- Performing any action that would charge a card or contact a real person
We escalate to you when
- A failure comes from outside your site, such as a platform change you did not make
- A repair would change what is measured, not only restore it
- Failures repeat for the same reason after a repair
How you know it held. Each month's record lists the runs actually performed and shows the result for every named event in each run, with DebugView evidence, so you can compare it with your own report figures.
How we keep it true
This service is never finished. Each month's record shows whether the named events still fire, and it continues until you end it.
Get one GA4 key event recording again, proven with a test event Job Each time it fires
One named action on your site produces one GA4 event with the agreed name, visible in DebugView and then counted as a key event.
As needed, priced as the one-off job
Each repair is the same job you can buy on its own, after your approval.
Make each order send one GA4 purchase event, not two or three Job Each time it fires
A test order creates exactly one purchase event with its own transaction ID, and reloading the confirmation page does not create another.
As needed, priced as the one-off job
Offered only for shops where orders can be test-placed.
What is included, and what is not
- A monthly record of each test event: result, DebugView evidence and date, and the list of scheduled runs actually performed that month
- A repair note for each failure, naming the likely cause, and the matching one-off job if a change is needed
- A short comparison of key event counts with last month and an explanation of any drop we can see
Included
- Up to ten named test events on one site and one GA4 property
- A scheduled run of those events on the live site in a debug-enabled browser, on a cadence agreed in writing before the service starts. A run is one pass through all the named events: each action performed once with test values and the result read in DebugView
- A comparison of key event counts against the previous month, read through a read-only role. For a shop, the month's GA4 purchase count is also compared with the order count you send us (a number only, no customer data)
- A monthly written record that lists the runs actually performed, with evidence, and a repair note for any failure
Not included
- Repairs themselves: each needed change is the matching one-off job at its listed price, after you approve
- Fixing campaign tagging, ad conversions, consent set-up or server-side tags unless added to the agreement
- Round-the-clock cover or any guaranteed response time
- Reconciling GA4 to your accounts
- Any promise about ad performance, revenue or rankings
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
For each named event, the monthly record contains a run result with a DebugView screenshot showing the event name and the time of the test, and it lists every scheduled run that was actually performed and any run that could not be performed.
Evidence: The monthly record, which you can compare with the event list and the cadence in the agreement.
The first monthly record shows a negative control agreed with you in writing before the service starts: either an action that must not fire a named event (for example the form sent with a deliberate validation error), run in every pass and reported as no event, as expected; or a test change that you publish and then revert, which the next scheduled run reports with the right event named. This shows the record can report an absence; it does not prove every failure would be caught.
Evidence: The first-month record showing the control, its result and, for a published test change, the dates you published and reverted it.
Every failure in the month has a repair note naming the event, the evidence and the matching one-off job.
Evidence: The repair notes attached to the monthly record.
Sign-off. You read each monthly record and decide on repairs. A repair counts as delivered when you approve and publish it.
If it fails. If a scheduled run could not be performed, the record says so and lists that run as not performed. If the service is not working for you, you can end it at the end of any month.
When it fits, and when we stop
It fits when
- Test events can be performed on the live site without a real payment or a real customer contact
- You can grant a Viewer role on the GA4 property and read access to the Tag Manager container. Whether Viewer is enough to open DebugView, and whether read access shows the container's version history, is confirmed with you at onboarding, before the first scheduled run; if either is not, we name the lowest role that is and you decide
- A person on your side receives the monthly record and decides on repairs
We stop and tell you if
- The only test route is a live purchase or a message to a real customer
- Most failures come from changes outside the site that you cannot influence
- The number of named events grows past ten, so we agree a different scope
What could go wrong
We change nothing in your accounts. Ending the service leaves everything exactly as it is, with open repair notes handed back.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Test runs create fake events in real reports. | Tests use a recognisable test value, are listed in each record, and can be filtered by you. |
| A passing test is mistaken for proof that every real visit is measured. | The record states exactly what was tested and says that it does not cover every browser, device or consent choice. |
Each monthly record is checked by a reviewer separate from the run that produced it before it is sent. No human supervisor is included unless your agreement names one. At launch the work is largely automated, and we say so.
Stays with a person
- You approve and publish every change
- You approve any new test event
Access we would need
- A Viewer role on the GA4 property
- Read access to the Tag Manager container
Questions
How is this different from a one-off fix?
A one-off fix repairs one named fault once. This service runs your named events on an agreed schedule and reports, with evidence, when one changes.
Do you change anything on my site?
No. We read results and write a repair note. Any change is a one-off job that you approve and give the access it needs, and you publish it.
Does a pass prove all my data is right?
No. It proves the named test events fired as agreed at the time of the run. The record says what it did not cover.
Also part of
Send an enquiry
Send us
- The site address and the list of events that matter most, up to ten
- How the site is built and who changes it
- No logins and no customer data.
Later, once you agree
- A Viewer role on the GA4 property and read access to the container, granted to the identity we agree with you before work starts
- A safe test route for each event, such as a test form recipient or test-mode checkout
- The person to receive reports and the person who approves repairs
- For a shop, the month's order count from your shop's own admin, sent to us each month: a number only, with no customer data
Your site, accounts, containers and data stay yours. We read results with a Viewer or read-only role that you grant to an identity we agree with you in writing before work starts. We make no changes in your accounts, we never ask for passwords, and you can remove access at any time.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “tracking-monitor-for-breakage-monthly” as the subject.