Synthetic data layer specification for a small shop: which push, when, with which fields

Why write it down first

A data layer specification is the contract between the site and the tags. It lists each page or action, the push that must happen, the fields it must carry and their types. Google's data layer documentation stresses using identical names for the same concept on every page and warns that overwriting the array or declaring it late breaks tags; a written list makes those rules checkable.

The table below is invented for a small shop. It is a layout to copy, not a recommendation for any real site, and it has not been run against any production system.

• Agree names and types before building any tag.
• Give each row an owner on the site side.

The specification

The first column names the page or action, the second the required push, the third the fields and types, the fourth an example value.

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

page / action          | push (always clear first)                          | required fields (type)                                        | example value
product page           | ecommerce:null, then event 'view_item'              | currency (string), value (number), items (array)              | GBP, 20.00, [SKU-A]
add to cart            | ecommerce:null, then event 'add_to_cart'            | currency, value, items[].item_id, items[].quantity (number)   | GBP, 20.00, SKU-A x1
begin checkout         | ecommerce:null, then event 'begin_checkout'         | currency, value, items[]                                      | GBP, 50.00
order confirmation     | ecommerce:null, then event 'purchase'               | transaction_id (string), currency, value, items[]             | TEST-1001, GBP, 50.00
enquiry form success   | event 'enquiry_sent' (no ecommerce object)          | form_name (string)                                            | contact-main

items[] fields:  item_id (string, required)  item_name (string)  price (number)  quantity (number)
rules:  names are lowercase with underscores;  numbers are numbers, not strings;  no personal data in any field;
        the data layer is declared above the container snippet and is only ever pushed to;  one data layer per page.

Checking the site against it

Open Tag Manager preview on each named page, perform the action, and compare the data layer contents with the row. A field that is present but the wrong type, such as a price sent as text, passes a glance and fails a calculation. A missing clear-first push shows up as items carried over from an earlier event. A field named differently on two templates shows up as one report column and one blank.

Record specified against observed values in a table; that table is the evidence that the site matches the specification.

• Check types, not just presence.
• Test the smallest and largest carts, not only a typical one.

What this does not do, and where it leads

The specification does not make the site push anything; someone must implement it in the theme or platform. It does not promise any report result. A specification is delivered as part of rebuilding a site's measurement, from £4,500 as an untested proposal, and the shop funnel events from £795 implement the ecommerce rows. Payment follows sign-off in both cases. Send the platform name and your five key actions; no logins or store data.