SENRIKO is now in early access - monitor your first website free. Explore SENRIKO

Keeping our test submissions out of your analytics

Keeping our test submissions out of your reports

Every form check we run sends one real, clearly marked submission through your form. This page shows how to keep those out of your analytics reports - and which way of doing it quietly costs you something.

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.

How much traffic this actually is

Less than most people expect. A daily form check is thirty sessions a month per form. On the Free plan the whole allowance is thirty browser checks. Even an hourly check on the largest plan is around seven hundred - noise against any site with real traffic, and worth excluding anyway, because a conversion count that is wrong by a known amount is still wrong.

How to recognise them

Our submissions carry two marks, and both survive everything we do to a monitor:

The traffic source on every visit we make:
utm_source = senriko-monitor
The address on every submission, always on this domain:
@checks.senriko.com

Collection or reporting: the one decision that matters

Excluding at collection means the events never arrive. Excluding at reporting means they arrive, are labelled, and you choose not to count them. The second is almost always right: our sessions are also the evidence that your tracking works at all, and a check that says 'the conversion recorded' is only possible if the conversion was recorded somewhere you can see. Throw the events away at the door and you throw that away with them.

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.

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.

The recommended way is to exclude by source label at the reporting level. The events are collected, stay out of your comparisons and reports, and the check keeps working.

Recipes

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.

Use 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.

Official documentation

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.

If 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.

Official documentation

Meta

Events Manager → your dataset → Event filters. Filter on the utm_source parameter matching senriko-monitor.

Meta’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.

Official documentation

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.

Keeping them out of your CRM

Analytics is one half. The submissions also arrive as enquiries.

How to filter them in your CRM →