The data layer and custom events

Video lecture

15 chapters · about 8 min · full transcript

Coming soon

Chapter 1 of 15

The data layer and custom events

What a data layer is
The push pattern
Developer specifications
Timing and single-page apps
Contract tests

The narrated lecture is in production

Every chapter is scripted and ready. Browse the chapters and read the full transcript now — the video will appear here when it’s published.

Chapters

Transcript of the narration, chapter by chapter.

0:00 The data layer and custom events

Here's a question that separates fragile tracking from reliable tracking. When your website redesigns its contact form next month, will your lead tracking break? If your tags read button text or CSS classes, probably yes. If they read a data layer, probably not. In this lecture you'll learn what a data layer is, the push pattern, how to write a developer specification that gets implemented correctly the first time, how timing and single-page apps change things, and how to protect measurement with an automated contract test.

0:37 Why a data layer

Why does the data layer matter? Because it decouples what happened on the site from which tools receive it. When the site pushes generate lead, the tag manager can forward it to G A four, an ad platform and a C R M integration, without the developer knowing about any of them. The site speaks one clear language, and every tool listens. That makes tracking resilient to redesigns, easier to test, and much easier to govern for consent and privacy.

1:12 The departures board

Here's an analogy. The data layer is like an airport departures board. The airline, that's your website, posts accurate information: flight, gate, time. Everyone who needs it, passengers, cleaners, caterers, reads the board. Nobody has to phone the pilot. If the airline changes the terminal's design, the board still shows the same fields. In G T M, the board is an array called data layer, and the website adds information with data layer push.

1:44 The push pattern

The push pattern is simple. Initialize the array if it doesn't exist, then push an object. If the object contains an event key, it can trigger tags. For example: event generate lead, form id contact main, service paid social, lead type consultation. In G T M, you then create data layer variables for form id, service and lead type, a custom event trigger that matches generate lead, and a G A four event tag with those parameters mapped to the variables.

2:19 E-commerce pushes

E-commerce needs one extra habit. Google's documented structure uses an e-commerce object inside the push. Always clear the previous e-commerce object before pushing a new one, by pushing e-commerce null. Otherwise values can leak between events, and a purchase might carry items from an earlier view item. Many e-commerce platforms have plugins that produce this structure. Verify the output rather than assuming it's right, because plugins get updated too.

2:49 Developer spec

Now the developer specification, which is where most projects succeed or fail. Developers need precise instructions, not please track the form. A good spec says which event, exactly when: after the server returns success, and not on validation errors or network failures. It lists each key with its type and allowed values. It lists the pages. It gives test cases: submit valid, see one event; submit invalid, see none. And it says no personal data, ever: never name, email, phone or message text.

3:25 Timing and SPAs

Timing and ordering matter too. Data needed on page load, like page type, content group or whether the user is logged in, should be pushed before the tag manager container snippet, or at least before the Google tag fires, so page views carry it. Interaction events are pushed when they happen. And single-page applications, the React, Vue or Angular kind, don't reload between views. So either developers push a virtual page view on route change, or you rely on G A four's history change page views. Not both, or you'll double count.

4:05 Example 1: WordPress quote form

First example, a simple one. A logistics company in Jeddah uses a WordPress form plugin that redirects to a thank-you page on success. Option one: fire generate lead on the thank-you page view. Simple, but anyone who bookmarks or revisits the page creates a false lead, and you can't tell which form was used. Option two: a developer adds a small script to the plugin's success callback that pushes generate lead with form id and service. Option two is more accurate and richer. If option one is all you can do, document the limitation.

4:46 Example 2: a Riyadh SPA

Second example, a business case. A Riyadh fashion retailer's site is a React single-page app. Page views were double counted, because developers pushed a virtual page view on route change while G A four's history change page views were also on. The team picked one method, the developer push with page type and content group, turned off the history change option, and added an automated contract test for route changes. Engagement metrics stabilized, and content group reporting finally matched the site's structure.

5:22 Watch me do it, part 1

Watch me write a push from a real success callback. The form submits with fetch to the quote endpoint. I read the JSON response. If the response isn't OK, or the success flag is false, I show the error and return, with no analytics event. Only after success do I initialize the data layer and push generate lead, form id quote request, service from a controlled dropdown, and lead type quote. Never the name, email, phone or message. Then I show the thank-you message.

5:59 Watch me do it, part 2

Then I protect it with a contract test. In the developers' end-to-end tests, for example with Playwright, the test fills the service field, clicks submit, waits for the thank-you message, and reads the data layer. It expects exactly one generate lead push, with form id quote request and service S E O, and it fails if anything that looks like an email appears in the push. Now, if a redesign breaks the push, the build fails before the site goes live, not three weeks later in a report.

6:37 Server-side tagging

A quick word on server-side tagging, since it comes up in every data layer conversation. In server-side tagging, the browser sends data to a tagging server you control, often on your own subdomain, which forwards it to vendors. It can give you more control over what each vendor receives and reduce third-party scripts in the browser. But it adds hosting cost and complexity, and it doesn't remove the need for consent. Legal obligations follow the data, not the architecture. The Privacy-First Measurement course covers it in depth.

7:15 Common mistakes

Common mistakes. Pushing personal data for convenience. Never do it. Not clearing e-commerce between pushes. Relying on thank-you page URLs alone for important conversions. Changing data layer key names without telling the analytics team, so G T M variables silently go undefined. And pushing events before the data layer is initialized, which overwrites it.

7:38 Recap

Recap. The data layer separates what happened on the site from which tools receive it. Give developers exact specs: when to push, keys, allowed values and test cases. Push on confirmed success. Clear the e-commerce object before each new e-commerce push. Choose one page view method on single-page apps. Protect it all with a contract test. And remember that server-side tagging adds control, not consent exemptions.

8:07 Try this now

Try this now. Write a developer specification for one key event on a site you know, using the template in the lesson: the event, when it fires, the keys and allowed values, the pages, test cases for success and failure, and a no personal data line. Then ask a developer to add the contract test from the lesson to their test suite.

What is a data layer?

A data layer is a JavaScript object — in GTM, an array called dataLayer — where the website places structured information for tags to read. It decouples what happened on the site from which tools receive it. When the site pushes generate_lead, GTM can forward it to GA4, an ad platform and a CRM integration without the developer knowing about any of them.

The push pattern

Developers add information with dataLayer.push(). Pushes containing an event key can trigger tags:

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: "generate_lead",
  form_id: "contact_main",
  service: "paid_social",
  lead_type: "consultation"
});

In GTM you then create:

Data Layer Variables for form_id, service, lead_type.
A Custom Event trigger matching generate_lead.
A GA4 event tag with event name generate_lead and parameters mapped to those variables.

E-commerce in the data layer

For e-commerce, Google's documented structure uses an ecommerce object. Always clear the previous ecommerce object before pushing a new one so values do not leak between events:

dataLayer.push({ ecommerce: null });
dataLayer.push({
  event: "add_to_cart",
  ecommerce: {
    currency: "GBP",
    value: 42.00,
    items: [{ item_id: "SKU-778", item_name: "Ceramic mug set", price: 21.00, quantity: 2 }]
  }
});

Most e-commerce platforms have apps or plugins that produce this structure; verify the output rather than assuming it is correct.

Writing a developer specification

Developers need precise instructions, not "please track the form". A good spec contains:

EVENT: generate_lead
WHEN:  After the server returns success for the contact form (HTTP 200 + success flag).
       Do NOT push on validation errors or network failures.
PUSH:
  event:     "generate_lead"
  form_id:   string, one of: contact_main | quote_request | newsletter_footer
  service:   string, one of: seo | paid_social | web_design | other
  lead_type: string, one of: consultation | quote
PAGES: /contact, /services/*, footer on all pages
TEST:  Submit valid form in staging -> event appears once in GTM preview with correct values.
       Submit invalid form -> no event.
NO PII: never include name, email, phone or message text.

Handing developers this level of detail saves days of back-and-forth.

Timing and ordering

Order matters. Data needed on page load (for example page_type, content_group, user_logged_in) should be pushed before the GTM container snippet or at least before the Google tag fires, so page views carry it. Interaction events are pushed when they happen.

For single-page applications (many React, Vue or Angular sites), the page does not reload between views. Developers should push a virtual page view event on route change, or you rely on GA4's history-change page views — but not both, or you will double count.

Server-side tagging (concept)

In server-side tagging, the browser sends data to a tagging server you control (for example on your own subdomain), which then forwards it to vendors. Potential benefits include more control over what data each vendor receives, the ability to strip or hash fields centrally, and fewer third-party scripts in the browser. It adds hosting cost and technical complexity, and it does not remove the need for consent: legal obligations follow the data, not the architecture. Consider it once your client-side implementation is clean and well governed.

Worked example: a quote form in a WordPress site

A logistics company in Jeddah uses a popular WordPress form plugin. The plugin redirects to a thank-you page on success. Two options:

Thank-you page trigger — fire generate_lead on page view of /thank-you. Simple, but anyone who bookmarks or revisits the page creates a false lead, and you cannot see which form was used.
Plugin success hook — a developer adds a small script to the plugin's success callback that pushes generate_lead with form_id and service.

Option 2 is more accurate and richer. If option 1 is the only choice, add a URL parameter from the form (such as ?form=quote) and a referrer check to reduce false positives, and document the limitation.

Hands-on: pushing from a real success callback

Most modern forms submit with JavaScript. Push only after the server confirms success:

async function submitQuote(form) {
  const res = await fetch('/api/quote', { method: 'POST', body: new FormData(form) });
  const data = await res.json().catch(() => ({}));
  if (!res.ok || !data.success) {
    showError(data.message || 'Please check the form');
    return;                                     // no analytics event on failure
  }
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    event: 'generate_lead',
    form_id: 'quote_request',                   // controlled values only
    service: form.elements.service.value,       // e.g., seo | paid_social | web_design
    lead_type: 'quote'
    // never: name, email, phone, message text
  });
  showThankYou();
}

Two details matter: the push happens after res.ok and the success flag, and values come from controlled lists, never from free-text fields.

Hands-on: a data layer contract test

Ask developers to include a small automated check in their end-to-end tests so a redesign cannot silently break measurement:

// Example with Playwright
await page.fill('#service', 'seo');
await page.click('#submit');
await page.waitForSelector('.thank-you');
const pushes = await page.evaluate(() => window.dataLayer.filter(e => e.event === 'generate_lead'));
expect(pushes).toHaveLength(1);
expect(pushes[0]).toMatchObject({ form_id: 'quote_request', service: 'seo' });
expect(JSON.stringify(pushes[0])).not.toMatch(/@/);   // crude guard against emails

Second worked example: a Saudi e-commerce app built as a single-page app

A Riyadh fashion retailer's site is a React single-page app. Page views were double counted because the developers pushed a virtual page view on route change while GA4's history-change page views were also on. The team chose one method (developer push with page_type and content_group), disabled the history-change option in enhanced measurement, and added a contract test for route changes. Engagement metrics stabilized, and content-group reporting finally matched the site's structure.

Common mistakes

Pushing PII (email, phone) "for convenience" — never do this.
Not clearing ecommerce between pushes, so a purchase carries items from an earlier view_item.
Relying on the thank-you page URL alone for important conversions.
Changing data layer key names without telling the analytics team — GTM variables silently go undefined.
Pushing events before dataLayer is initialized, overwriting it.

Data layer governance

Treat the data layer as a product interface. Version it, document it alongside the tracking plan, and include analytics checks in the site's release testing so a front-end redesign does not silently break measurement.

The data layer separates what happened on the site from which tools receive it.
Give developers exact specs: when to push, keys, allowed values and test cases.
Clear the ecommerce object before each new e-commerce push.
Server-side tagging adds control, not consent exemptions.

Write a developer specification for one key event on a site you know using the template in this lesson, including test cases for success and failure.

Enrol for free to save your progress

Reading is always free. Enrol to keep your place, take the final assessment and earn a verifiable certificate.

The data layer and custom events