In short
What is measured
the structure of the data layer your page publishes and the validity of its event names.
When it’s triggered
when the structure has defects, or when the standard events aren’t valid.
Why it matters
data keeps arriving, so nobody notices until an answer is needed that isn’t there.
Severity in Wakaris
Improvement. It only applies where measurement is installed: without it, there’s nothing to review.
What this finding is and what it measures
Having measurement installed and having usable measurement are two different things, and this finding is about the second. It doesn’t ask whether you measure, but whether what you measure arrives in a form someone can use later.
It reviews two things. The first is the data layer: the object your page publishes so measurement tags read from it instead of inferring information from the screen. It’s documented as a JSON-type structure, a single global list to which the page keeps adding values and notices that something has happened.
The second is event names. Analytics platforms distinguish three kinds: those they collect on their own, recommended ones —which they already know how to interpret and have ready-made reports for— and the ones you make up. This finding checks whether the standard events you declare are valid, and valid has a published definition: the name can’t exceed 40 characters, only allows alphanumeric characters and underscores, must start with a letter, and there are reserved names that can’t be used.
How it’s measured
Wakaris analyzes the URL you give it, reads the data layer that page publishes and the events it declares, and tells you which of the two pieces of evidence fails, with the severity of the finding and without installing anything. That’s the direct way to know where you stand.
Scope matters a lot here, more than in other findings. A single page is observed, in a single load and without anyone interacting. Everything that only happens when someone buys, submits a form or clicks a button is left out: what you see is what the page declares when it loads. So a clean result doesn’t mean all your measurement is set up correctly, it means what’s declared when that page loads is.
And there’s a second limit, one of nature: the check looks at form, not truth. A flawlessly structured data layer can be publishing the wrong price or a category that doesn’t match, and no automated review can know that. For that you need someone who knows the business to compare.
Why it matters
What’s characteristic of this finding is that the cost is invisible and arrives late. Data keeps coming in, dashboards fill up, nobody sees an error. The problem shows up months later, when someone asks a specific question and the answer isn’t anywhere.
Names are half the matter. Using the recommended names is what gives you the reports the platform already has built; a made-up name forces you to build each report by hand, and the documentation itself warns that recommended events must be set up precisely because the platform can’t send them on its own.
Structure is the other half, and there the rules are strict. The documentation is explicit on three points: only one data layer is supported per page, its name is case-sensitive, and assigning values to it directly instead of adding them overwrites everything that was there before. Any of the three turns measurement into data that arrives half-complete.
And worst of all: history can’t be fixed. What wasn’t measured properly in March can’t be recovered in June.
Common causes
The most frequent cause is ordering. The data layer is created after the measurement code, when the documentation asks for it to be created as high as possible in the source code, above it, and in the defensive form that reuses it if it already exists. Placed afterwards, tags that fire early find nothing.
The second is assigning instead of adding. Using the data layer directly overwrites any value already there, and that silently erases what another piece of code had just left in it.
The third is duplication: two data layers, or one with its name in different capitalization, when only one is supported per page and the name is case-sensitive.
And the fourth is naming, almost always from different hands at different times. Each person names the same concept their own way, and the documentation insists on just the opposite: if you call the category one thing on one page, it has to be called the same on the others.
How to fix it
Wakaris tells you which of the two pieces of evidence fails, and the order of the fix follows from that.
If the structure fails, start with placement: create the data layer as high as possible, above the measurement code, reusing it if it already exists. Always add values instead of assigning them. And keep a single data layer per page, with its name written exactly, capitalization included.
If the names fail, rename the events to the ones your platform recognizes, and do it before building anything on top: changing them later forces you to redo everything that relied on the old ones. Use the same name for the same concept on every page.
And finally, the fix that lasts longest and isn’t technical: write down the naming plan and leave it where whoever builds the next page will find it. It’s the fix that degrades fastest, because every new page reopens it. When you’re done, run the page through Wakaris again.
Table comparing a well-built data layer with the four usual defects and their correction
Brief to generate the image
Editorial illustration for a Wakaris technical guide. Subject: Table comparing a well-built data layer with the four usual defects and their correction. Style: white background with a soft lime→pale green wash (#F8F7D6 → #E2F2DC), green→lime gradient accent (#8ED390 → #DCD86F), near-black ink (#12150B), pill shapes and rounded corners, soft shadows, clean schematic look, no photography. Format: 16:9, 1440 pixels wide. No legible text: any label, code or figure is shown as gray placeholder bars. The caption carries the meaning, not the image. No real logos or third-party brands. No recognizable people. Tags: quality, tracking, table, compares, layer, data, well, built
Ask your AI
If you want to dig into your specific case, copy one of these two prompts and paste it into the AI you use. Pick the one that fits your situation.
I already have the finding measured with Wakaris and want to fix it
Act as a professional, careful web technical auditor. Your goal is to help me understand a specific finding about my website and decide what to do about it, without making anything up. Context: I got this finding with Wakaris, a tool that analyzes a website across 9 areas (performance, SEO, security, social, market, AI, user experience, accessibility and legal) and explains each problem so that every profile on a team can understand it. The finding is: Tracking quality. It reviews whether the data layer my page publishes has the expected structure and whether the standard events it declares are valid. Reference: the finding is triggered when the structure has defects or when the standard events aren't valid. Paste the Wakaris result here: which of the two pieces of evidence fails, on which page and, if it says so, in which event or which part of the structure. If you don't have it, tell me and I'll explain how to get it before we continue. Rules you must follow at all times: 1. Don't assume anything about my website. Every piece of data you use must come from what I confirm to you or from what Wakaris has measured. If you don't know it, ask me before stating it. 2. Before giving me conclusions, ALWAYS ask me these questions, all together and in plain language, to find out whether this finding really affects me and where: a) What platform is your website on and how was measurement installed: with a plugin, with hand-written code, or both? b) Who set up the measurement and when? Has it gone through more than one person or agency? c) Which actions do you really care about measuring? (contacts, purchases, sign-ups, downloads, calls) d) Do you know whether your website publishes a data layer, or are you not sure? e) Are your event names written down in some document, or was each one added when it was needed? f) Are you making decisions with that data right now, or not using it yet? g) If the code needs changing, would you do it yourself, an in-house technician or an agency? 3. Every statement or recommendation must be reasoned in relation to MY context, not in general. If you recommend something, explain why it applies to my case. 4. Always state your level of certainty. If something is a hypothesis because you can't check it, say so: you can't see my website, you reason from what I tell you. 5. Don't suggest irreversible or risky technical changes (renaming events that already feed reports, changing measurement in production) without first warning me of the risk, that previous history can't be recovered and that a test environment is advisable. 6. Warn me explicitly if a change you suggest breaks the continuity of my data: I'd rather know beforehand than discover it in next month's dashboard. 7. If you need data that can only be obtained by analyzing the website (confirming which evidence fails, or whether the fix worked), tell me and recommend I run the page through Wakaris again: that gets checked, not guessed. 8. The final decision is mine, not yours. Your role is to help me understand and prepare the action, not to decide for me. 9. If the fix is beyond what I can do myself, or a team is going to carry it out, help me get the problem ready to hand over: what it is, where it is, why it matters and what needs to be done, in an actionable format for that person. Source of this finding: https://www.wakaris.com/en/guides/marketing/tracking-quality To check it or check it again: https://www.wakaris.com/ Start by briefly introducing yourself in your role and asking me the first block of questions.
I haven’t measured it yet and want to check whether my website has this problem
Act as a professional, careful web technical auditor. I'm looking into whether my website has a specific problem and I want you to help me find out honestly, without taking it for granted. Context: I came to this through Wakaris, a tool that analyzes a website across 9 areas (performance, SEO, security, social, market, AI, user experience, accessibility and legal) and explains each problem so that every profile on a team can understand it. The problem I want to look into is: Tracking quality. It's about whether the data layer my page publishes has the expected structure and whether my event names are the standard ones. Reference: the problem exists when the structure has defects or when the standard events aren't valid. I DON'T know yet whether my website has it: I want to find out. Rules you must follow at all times: 1. First and most important: this is CHECKED by reading my page's code, and you can't do that from this conversation. Make it clear from the start that you won't be able to give me a definitive "yes, you have it" or "no, you don't", only a hypothesis based on what I tell you. 2. Don't assume anything. Before giving me any assessment, ALWAYS ask me these questions, all together and in plain language, to estimate whether I'm likely to have the problem: a) Does your website have measurement installed? Did you set it up, a plugin or an agency? b) Has the measurement gone through more than one person or company since it was set up? c) Do you know whether your website publishes a data layer, or are you not sure? d) Do you have it written down somewhere what your events are called and what each one measures? e) Has it ever happened that a report didn't add up, that conversions were missing or that the same event was counted twice? f) Was the website redesigned or the template changed without reviewing the measurement? g) What platform is the website on? (WordPress, Shopify, custom-built, other; or I don't know) 3. Based on my answers, give me a clear estimate of whether it's LIKELY or UNLIKELY that I have it, and which of the two things would be the suspect, reasoned from what I've told you and explicitly marked as a hypothesis, not a diagnosis. 4. Tell me directly that the only way to really know is to check it, and that I can do it for free and without creating an account by running my website through Wakaris, which will tell me which evidence fails and, along the way, the status of the other areas. 5. If I ask you how to check it by hand, don't hide it from me, but remind me that Wakaris does it faster, on the real page and with extra information I don't get by hand. 6. If checking it turns out that I do have it, tell me the next step is to understand how it affects me and how to fix it in my specific case, and remind me that history already collected can't be fixed retroactively. 7. The conclusion and the decision are mine, not yours. You help me find my bearings. Source of this finding: https://www.wakaris.com/en/guides/marketing/tracking-quality To check it: https://www.wakaris.com/ Start by briefly introducing yourself in your role, making point 1 clear, and asking me the block of questions.
Frequently asked questions
If data is reaching me, is the tracking set up correctly? +
Not necessarily. Data arriving and data being useful to answer questions are different things. This finding is about exactly that difference: measurement is in place, information comes in, and yet the structure or names that let you make use of it later are missing.
Does it matter what I call my events? +
Yes. Platforms distinguish between events they collect on their own, recommended events they already know how to interpret, and ones you make up. Using the recommended names gives you ready-made reports; making up the name forces you to build each report by hand, and some things can’t be recovered.
Can I have two data layers on the same page? +
The documentation is explicit: only one is supported per page, and its name is case-sensitive. Two layers, or one with a misspelled name, is one of the most common ways information gets lost without anyone seeing an error.
Can I fix the data I already collected wrong? +
Not retroactively. Tracking decides what gets stored at the moment it happens, so whatever was measured wrong stays that way. It gets fixed from today on, which is why it’s worth reviewing before you build reports or decisions on top of it.
Sources cited
- developers.google.comThe data layer, Google for Developers: the data layer as a JSON-type structure, creating it as high as possible in the source code and in reusable form, adding values versus direct assignment that overwrites, the case-sensitive name, the limit of a single layer per page and naming consistency across pages.
- developers.google.comSend events, Google for Developers: event names can’t exceed 40 characters, only allow alphanumeric characters and underscores, must start with a letter, and each event supports at most 25 parameters.
- developers.google.comRecommended events, Google for Developers: the three kinds of event, and that recommended ones must be set up because the platform can’t send them on its own.
Updated: September 8, 2026.
This article is part of Wakaris, which analyzes your website across 9 areas and explains each finding so that every profile on your team can understand it.