Types of Tests

Data Layer Testing: Your Decisions Are Only as Good as Your Data

An event that won't go away, a purchase value of zero, a product ID that changes format. The tagging plan breaks silently, and the error isn't noticed until weeks later, when the numbers don't add up.

GA4, GTM, and the data layerVerified at every stepWithout writing any code

Details of a data layer test run in Mr Suricate, including the captured query and the downloadable data layer report

They trust us

3 million scenario runs per month100+ clients15 types of tests covered

Retail, banking, manufacturing, transportation, services. Hosting in the European Union, French-language support, personalized assistance during the startup phase.

In a nutshell

A data layer test verifies that the events sent to your analytics tools are properly transmitted, complete, and compliant with the tagging plan. A broken tag doesn’t cause any visible issues on the screen—it silently empties your dashboards. This check is performed during the testing phase, before the system goes live.

data layer, tagging plan, consent: the definitions are in the QA glossary.

A broken tag doesn't break anything else

That’s what makes it dangerous. The site works perfectly—customers make purchases, and no one reports any issues. Meanwhile, the purchase event is recorded with a zero amount, and you’re managing your advertising budgets based on inaccurate data. The problem isn’t discovered until the end of the month, when it’s too late to recover the lost data.

The Event at the Right Time

The script tracks the process and verifies that at each step, the expected event is triggered exactly once.

Content, not just the trigger

Product ID, amount, currency, quantity. An event that starts with an empty value is just as serious as a missing event.

Respect for Consent

What happens before and after the user makes a choice. A tag that is set despite a refusal is a compliance issue.

With every delivery

The tagging plan is reviewed just like everything else—not just once a year during an audit.

The tagging plan is reviewed before production

The tagging verification process is triggered from your CI, runs on your production environments, and feeds back into where your teams are already working. No need to retool.

1 Triggering Your tools stay in control

GitLab
Jenkins
Microsoft Azure
API Call
Planning

2 Execution

Your scripts run on your production environments

Web Tour
Native iOS and Android Apps
Real Mobile Farms
APIs and Internal Feeds

3 Restitution The results are delivered right to your workplace

Jira
Slack
SMS
Webhook
API

And maintenance that stands the test of time

Reusable blocksA change updates all scenarios that use it
AI-Assisted CorrectionSuggested corrections for scenarios with errors
Grouping IncidentsSimilar anomalies are processed only once

How Automated, Line-by-Line Validation Makes a Difference

Without tagging verificationWith Mr Suricate

Without tagging verification

With Mr Suricate

The discrepancy is revealed at the end of the month in a report.

It will be revealed on the day it goes live.

We check the tags manually before major events.

They are checked with every delivery.

An event that starts with no entries is treated as an event that has started.

The event content is moderated.

Once data is lost, it's gone.

The delay is limited to a few hours.

This issue falls under the data team's purview, but there's a bug in the code.

The test is in the same test booklet as the rest.

Consent is presumed to have been given.

It is verified in both cases.

ResultA tagging plan verified with every delivery, rather than a data discrepancy discovered a month later.

Verifying Consent, Step by Step

Decline

The script opens the banner and declines the collection.

Controlling Silence

No measurement tag should be sent. If one is sent, the test fails.

The character reconsiders his decision and agrees to the donation.

Check the return

The events are restored, complete, with their values, and in the correct order.

FOR THE DATA TEAM

A missing event is detected before the report becomes inaccurate

The values are checked, not just the trigger

Media and product decisions are based on verified data

FOR THE DPO AND THE LEGAL DEPARTMENT

A comparison of beacon behavior before and after the user's selection

The sequence is repeated with every delivery, not just once a year

A line is drawn showing the exact location where it occurred

WHITE PAPER · TEST AUTOMATIONWhat if your bugs no longer cost your business anything?The true cost of incorrect data, and how to build a sustainable testing strategy.

Download the white paper

“With Mr Suricate, we’ve automated label verification, secured our data, and gained the reliability we need to make strategic decisions without errors. Plus, it’s fun!”

Xavier ValetHead of Data Analytics, HelloWork

You're in charge of the tagging plan; we can handle the verification.

With Mr Suricate, your QA team isn't replaced—it's strengthened. You choose what to handle in-house and what to outsource: creating test scenarios, running them, or maintaining them over time.

1Identification of critical paths, front-end and back-end
2Writing Tests Without Code
3Continuous monitoring and alerts
4Scenario Maintenance and Development

ResultYou gain broader coverage without increasing your teams’ workload. And if you’d rather delegate everything, QA outsourcing takes over.

GO FURTHER

Other Types of Tests

Fifteen types of tests, four categories. Each one answers a different question about your application.

Functional TestsVerify that a feature produces the expected result from the user's perspective.Learn more GDPR TestingThe actual behavior of your consent banner and the trackers it controls.Learn more SEO TestingTags, redirects, and structured data, verified just like the rest of the site.Learn more API TestingCommunications between your services, tested directly without going through the interface.Learn more Visual testingPixel-by-pixel visual comparison to detect changes that no assertion can catch.Learn more Non-regression testingRe-run all validated test cases before each deployment.Learn more Security testingVerify what a user can actually access: permissions by profile, sessions, authentication, HTTPS.Learn more The 15 Types of TestsThe big picture: four categories, fifteen types, and where to start based on your situation.Learn more

Is there a term you don't understand? The automated testing glossary defines it.

YOUR QUESTIONS

Frequently Asked Questions

The most common questions we get about tagging control.

What is a data layer test?

This is a scenario that simulates a user journey and checks, at each step, the events pushed to the site's data layer. It verifies the presence of the event, its name, and the content of its parameters.

Does this cover Google Analytics and Google Tag Manager?

Yes. The check focuses on what your site actually sends to the data layer, which is the source of the data received by GTM and then GA4. This is the right level to check: we verify the data being sent, not how it appears in the destination tool.

Is it possible to verify that consent has been obtained?

Yes, and that's one of the most useful scenarios. The script can block cookies, then verify that no tracking tags are being sent, and do the opposite after acceptance. This serves as a check for both compliance and data quality.

When should these tests be administered?

With every production deployment, just as with regression testing. A tagging plan most often fails due to a change to the site that had nothing to do with the measurement—and thus fell outside the data team’s scope of attention.

Do you need a technical background to create these scenarios?

No. The flow is built just like any other scenario, and event handlers are added to the relevant steps. The preliminary work is editorial rather than technical: you need to know which event should be triggered and with what values.

Is tagging in a mobile app covered?

Yes. The data layer exists on both the web side and the native app side. The same scenario can verify that an event is actually being sent from the iOS or Android app, along with the details of the captured request.

What do we gain from an execution?

The intercepted request, along with its payload—which can be downloaded as JSON—and a dedicated data layer report. The session’s network logs can also be retrieved in HAR format, allowing the analysis to be replayed in developer tools.

Can we verify multiple events sent in a single request?

Yes. The block can parse a request that contains multiple events, and the GA4 retrieval feature merges the keys and values to compare what is sent with what is expected.

Should a tagging error result in immediate disqualification?

Not necessarily. One option causes the scenario to fail at the end rather than at the step where the error occurred: the run continues to the end, you see all the discrepancies from the session, and the verdict is delivered afterward.

How do you test the Google Tag Manager data layer?

By reading the data object at the moment the user takes action, and then comparing the events and their parameters to the tagging plan. The validation takes place during the test run, both in the test environment and in production.

Can a GA4 event be validated before it goes live?

Yes, that's the main use case. The scenario triggers the action, captures the event that was sent, and verifies its name and parameters. If the event disappears after being delivered, the discrepancy is reported before the data goes missing from your dashboards.

Do you only believe what you see?

A 30-minute demo of your own app. You'll see one of your workflows automated in real time, without writing any code.