Keeping our test submissions out of your reports
A form check is a real visit, so your analytics sees it. Exclude it at the reporting level: your numbers come out clean, and the check on your tracking keeps working.
Marks that never change
Our submissions carry two marks, and both survive everything we do to a monitor:
- Every visit’s source
utm_source=senriko-monitorIf campaign checks are switched on for a form, the same visits also carry utm_medium=senriko-check and utm_campaign=senriko-attribution. The source stays senriko-monitor, so a filter on the source excludes these visits too, and nothing you already set up needs to change.
- The address on every submission
…@checks.senriko.comUseful in your CRM, and for conversions that carry the address.
- The free UTM test
utm_source=senriko-scanThe free UTM Survival Test uses its own source, utm_source=senriko-scan. It blocks analytics and ad requests while it visits, so it sends nothing to GA4 or the ad platforms, but the visit can appear in your server logs with that source, like any visit from a tagged link.
Why they show up at all
A form check is a real visit. A browser opens your page, waits for your scripts, fills the form in and presses the button - which means your analytics sees a session, and if a conversion fires on submit, it sees a conversion. That is the point: if our submission did not produce the signal your real ones produce, the check would be measuring something other than what your customers do. The cost is that a handful of sessions a month are ours, and this page is how you keep them out of the numbers you report on.
Two ways to exclude, and only one is free
You can exclude our traffic when the data is collected, or when it is reported. The reports look the same either way. What differs is whether the events still exist for us to check.
At the reporting level
RecommendedA comparison or a report filter on the source senriko-monitor.
- events are collected
- they stay out of your reports and comparisons
- the “conversion recorded” check keeps working
At collection (an IP filter)
An internal traffic filter, or a data filter set to Exclude.
- events are never collected
- we cannot see whether conversions were recorded
- we show the check as unavailable, never as passed
An internal-traffic filter by IP address stops the events being collected at all - they never reach your property. That also switches off our strongest check on your conversion tracking: we can no longer see whether the conversions we sent were actually recorded, so we cannot tell you when your tracking silently stops working. If you have already set one up, you can keep it - we will simply say the check is unavailable and why, rather than pretending it passed.
Where to set it, platform by platform
Google Analytics 4
Admin → Data settings → Data filters, or a comparison on your reports. Filter on Session source exactly matching senriko-monitor.
Official documentationUse a comparison or a report filter rather than an internal-traffic filter by IP. A data filter set to “Exclude” on internal traffic drops the events before they are stored; a source-based exclusion leaves them in place.
Google Ads
Our submissions arrive with no ad click, so they are not attributed to a campaign and do not appear in your ad conversions. Nothing needs configuring.
Official documentationIf you import conversions from GA4, the exclusion you set there carries through - check that the imported conversion action is built on the same filtered view.
Meta
Events Manager → your dataset → Event filters. Filter on the utm_source parameter matching senriko-monitor.
Official documentationMeta’s blocking rules discard matching events entirely, which is a collection-level exclusion. Prefer a breakdown or a filtered report if you want the events kept.
How much traffic this actually is
- 30
sessions a month per form, checked daily
- ~700
at most, checked hourly on the largest plan
It is still worth excluding: a conversion count that is wrong by a known amount is still wrong.
Checking that the exclusion worked
Wait for one check to run, then open a report for that day filtered to source senriko-monitor. You should see exactly the number of sessions we say we sent - the figure is on the check card, as submissions per month. If you see more, something else is using the same label. If you see none at all and the check is running, the exclusion is happening at collection time rather than at reporting time, and the next section is what that costs you.
If it goes wrong
Two failures are common and both look like something else. An internal-traffic filter set to Exclude drops the events before they are stored, and no report can bring them back - our conversion monitoring then reads your form as producing nothing at all. And a filter matching the address rather than the domain stops matching the day a check is deleted and set up again, because the address carries the check's own id. Match the domain.
What the check does with them
We know exactly how many submissions we sent, when, and with what label. Comparing that with what your analytics recorded is the one check on conversion tracking that does not depend on your visitors doing anything.
If our submissions stop arriving in your analytics entirely, we do not report your tracking as broken - we mark the check unavailable and say that internal traffic is probably being filtered by IP. The monitor on your site page shows which state it is in.
Keep the enquiries out of your CRM tooDiscard them on your server: the header