GA4 series / Lesson 3
Build the event parameter QA table before trusting reports
When purchase is low, customers may have bought less, or the event may be missing, value may be empty, transaction_id may duplicate, or items may be broken. This lesson turns those checks into an event QA table.
Lesson output
GA4 event parameter QA table
Core move
Validate the chain before funnels
Next lesson
Consent Mode and privacy measurement
First-screen QA workbench
event name
What the action is called
trigger timing
When it fires
required params
Which parameters are required
QA method
Which proof accepts it
An accepted install does not accept event meaning
The previous lesson accepted one installation path and recorded the property, stream, Measurement ID, time zone, responsible lead, and test order. That proves the current path can send an order to the intended property. It does not prove that every event fires after the correct business action.
Keep the same 20oz tumbler, Shopify order #1008, and $48 payment. A GA4 event is one action record, a session is a visit, a user is an observed identity, and the Shopify order remains the order fact. transaction_id reconciles purchase with that order; it cannot accept the triggers and parameters for the three earlier steps.
This lesson turns view_item, add_to_cart, begin_checkout, and purchase into an acceptance map. Record the event name, trigger timing, event-scoped and item-scoped parameters, backend proof, responsible lead, and failure action. Use the same property time zone and complete date range for testing and next-day reports. If event meaning or parameters remain unverified, pause funnels, audiences, key events, and Ads imports.
Event contract spine
An event is a contract for a business action, not a technical log line
The same event name must fire after the same real action and carry the context later analysis needs. Define the contract, complete order, and acceptance sequence first so interactions remain practice rather than the only answer.
What this lesson decides
The previous lesson proved that the production property, web stream, and single sender can receive one purchase. That does not make a funnel trustworthy. Setup acceptance asks whether data reaches the intended destination. Event acceptance asks what the delivered action means. New terms include event contract, trigger timing, event-scoped parameter, item-scoped parameter, deduplication key, and counterexample.
This lesson decides whether downstream funnels, audiences, key events, and Ads imports may reuse these events. At completion, you can explain why each event fires, where its parameters come from, which backend proves it, what passes, what stops, and you have a filled event parameter QA table.
Fixed case: one order, four separate event contracts
The teaching store still sells a leakproof 20oz tumbler to the US market, and the property uses America/New_York. Shopify shows order #1008, GA4 uses transaction_id=TMB-1048, the item ID is TMB-20-OZ, quantity is 1, and the shopper paid $48 USD. The test uses one device, one consent state, and one release version.
The shopper views the item at 10:41:20, adds it at 10:42:05, starts checkout at 10:44:10, and pays at 10:47:32. These teaching timestamps prove order, not a required shopping speed. On a passing chain, each action fires once, the item stays the same across steps, and purchase uses transaction_id to return to Shopify order truth.
| Real action | Event contract | Event parameters | Item parameters | Evidence and pass | Failure move |
|---|---|---|---|---|---|
| Product detail becomes visible | view_item | currency=USD, value=48 | item_id=TMB-20-OZ, item_name, price=48, quantity=1 | Once after visibility; item matches the page | Repair the visibility trigger if it fires too early |
| Shopper successfully adds to cart | add_to_cart | currency=USD, value=48 | Same item_id, price, and quantity | Once after cart state changes; items match cart | If a failed click fires it, listen for success state |
| Shopper enters checkout | begin_checkout | currency=USD, value=48, coupon if present | Same item_id, price, and quantity | Once after checkout truly begins; value is explained | Tighten the boundary if cart view fires it |
| Payment succeeds and order exists | purchase | transaction_id=TMB-1048, value=48, currency=USD | Same item_id, price, and quantity | Once in DebugView and reconciled to Shopify #1008 | Missing ID/value/items or duplicates block activation |
Passing sample
Purchase appears once with transaction_id=TMB-1048, value=48, currency=USD, and an items entry for TMB-20-OZ, price 48, quantity 1. Shopify #1008 is paid, and the next-day report contains the record under the same property time zone.
Counterexample
A purchase before payment, empty transaction_id, zero value, missing currency, empty items, or two events for one order fails even when Realtime shows activity. Repair the trigger, mapping, or duplicate sender and rerun the same order. Do not hide the defect with a report filter.
Object and proof boundaries
An event is one action record, a session is a period of activity, a user is an analytics object observed through device, browser, identity, and consent boundaries, and the Shopify order is the payment and refund fact. One user can have several sessions, one session can contain many events, and one order should normally have one deduplicated purchase. Mixing these objects breaks funnel numerators and denominators.
Transaction_id helps deduplicate and reconcile purchase. It cannot accept view_item, add_to_cart, or begin_checkout; prove incrementality; or prove profit. If any contract lacks evidence, stop funnels, audiences, key events, and Ads imports and record the failure route.
Four-step event chain
Translate real shopper actions into GA4 events first
Event taxonomy is not memorizing a list of event names. Start with one 20oz tumbler order: the shopper views the product, adds it to cart, starts checkout, and pays. Each step maps to a GA4 event with its own proof and misread risk. This block is interactive. Choose the step you need to validate first.
Define all four steps from real state changes, not button labels. A failed add-to-cart request must not create add_to_cart, and opening a cart drawer is not begin_checkout. Write the business success condition before checking whether the tag fires afterward.
View_item is selected by default. Before clicking, state its proof: the 20oz product is actually visible, items contains TMB-20-OZ at price 48 and quantity 1, and the event appears once. Use the same action → trigger → parameter → evidence sequence for every later step.
Static default: view_item fires once after the product becomes visible with item_id=TMB-20-OZ, price=48, and quantity=1. It proves a recorded product view, not purchase intent or a later order. If it fails, repair visibility or item mapping before changing a funnel denominator.
When switching to add_to_cart, begin_checkout, or purchase, change both the success condition and proof. A purchase transaction_id cannot retroactively accept the first three steps. Each contract passes independently.
Main table
The QA table connects meaning, trigger timing, parameters, and proof
The event name says what happened, parameters describe the context, and QA method proves whether it can ship.
Business term boundary
Two business terms that get misread: ROAS and attribution
Event QA is not an ads lesson, but it directly affects ad decisions. Before purchase, value, currency, items, and transaction_id are verified, do not explain ROAS or debate channel credit.
ROAS
Return on ad spend, usually revenue attributed to ads divided by ad cost.
Where you see it: Google Ads, Meta Ads, GA4 Explorations, and weekly business review sheets.
If purchase duplicates, value is unclear, or currency is missing, ROAS can be inflated or depressed, and budget calls drift.
Attribution
The rule that assigns a purchase to a channel, ad, keyword, or touchpoint.
Where you see it: GA4 attribution reports, Google Ads conversion columns, and Shopify marketing reports.
If the event chain is broken, attribution disagreement is not a strategy problem yet. Fix events before debating channel credit.
Key event
An event marked as important to the business in GA4. The event is collected first; after QA passes, decide whether to mark it as a key event.
Where you see it: GA4 Admin Events / Key events, Advertising reports, and Google Ads conversion creation.
If purchase enters key events or Ads conversions before parameters pass QA, bidding, attribution, and conversion counts inherit dirty data.
Event boundaries
Use recommended events before inventing names
GA4 events are not one category. Separate automatically collected, enhanced measurement, recommended, and custom events before names grow out of control.
Event type describes naming source and ownership, not inherent reliability. Automatically collected data can reach the wrong property, enhanced measurement does not replace ecommerce events, recommended events still require correct parameters, and a custom event must justify why recommended semantics are insufficient.
Recommended events are selected by default because view_item, add_to_cart, begin_checkout, and purchase already have shared semantics. Read the recommended definition and parameters before declaring a gap. Do not duplicate them merely because internal language differs.
Current boundary
Recommended events
Use for
view_item_list, select_item, view_item, add_to_cart, view_cart, begin_checkout, purchase, and refund.
Common misuse
When a recommended event and its prescribed parameters fit, do not invent product_view or buy_success.
The static default is to use recommended GA4 ecommerce events and record official meaning, real trigger, required parameters, owner, and test-order proof in the dictionary. Correct spelling is not enough; the action and payload contracts must both pass.
If a custom event is necessary, document the business action that recommendations cannot express, its naming rule, parameter contract, and downstream readers. Otherwise keep the recommended event to avoid split funnel and audience definitions.
Event dictionary
The event dictionary is an acceptance record, not a naming sheet
Every event needs business meaning, trigger timing, required parameters, proof, and a responsible lead. Otherwise, an event can appear in DebugView while no one knows whether it can feed funnels, audiences, or ad imports.
Event name
Use recommended events and prescribed parameters first; add custom events only when recommended events cannot express the action.
view_item, add_to_cart, begin_checkout, purchase
Key event / Ads boundary
State whether the event has passed QA, can be marked as a key event, and can create or import a Google Ads conversion.
purchase: key event only after value/currency/items pass
Business meaning
Write the real buyer action in plain language.
Shopper successfully adds one item to cart
Trigger timing
State whether it fires on button click, cart update, checkout start, or order creation.
After cart updates, not on click only
Required parameters
List the parameters and item-array fields that must be present.
items, value, currency, transaction_id
Acceptance proof
Name which proof layer accepts it: DebugView, Realtime, test order, or next-day report.
DebugView event record + Shopify order #1008
Responsible lead
Name who fixes the event, who accepts it, and who decides whether it can feed reports or ad imports.
data lead, developer, media lead
Event acceptance map
Accept the four field layers before purchase enters reporting
Click the layer most likely to break. The detail panel shows backend proof, what breaks, the copyable lesson note line, and whether the next route should continue or pause.
Accept the four layers in dependency order: event_name says what happened, event-scoped parameters describe the action, item-scoped parameters describe product lines, and transaction_id finally links purchase to order truth. A complete later layer cannot repair an ambiguous earlier meaning.
Event_name is the default. Before clicking, use #1008 to state its backend proof, breakage, and stop action. The dynamic panel checks structure; it does not replace the filled contract.
event_name
Event name layer
Contract layer
event_name declares what the shopper actually did, such as view_item, add_to_cart, or purchase. It is not casual naming; it is the entry point for reports, funnels, and audiences.
Required backend proof
GA4 DebugView event name, Events table, test-device record, and the business action in the event dictionary must match.
What breaks
If one action is split into product_view, view_product, and pdp_view, later funnels and audiences fragment.
QA note line
event_name accepted: this purchase uses the recommended event name, not buy_success; DebugView and Events table match.
Next route / blocked move
Before the event name is unified, do not move into funnel analysis, audience reuse, or Ads import.
Static default: event_name=purchase appears once only after payment succeeds and Shopify #1008 exists. If thank-you load, button click, and order-status refresh can all fire it, stop activation and repair the trigger boundary. Transaction_id deduplication must not hide a bad trigger.
Across other layers, keep the static case: event parameters explain $48 USD, items explain TMB-20-OZ × 1, and transaction_id returns to #1008. All four pass before next-day reporting or Ads release.
Parameter acceptance
Parameter design matters more than event volume
A purchase without transaction_id, value, currency, and items is weak for revenue, product, funnel, and ad analysis.
items
The item array. It carries item-scoped parameters inside the event, such as product ID, name, category, variant, quantity, and price.
For a 20oz tumbler order, items should show item_id, item_name, quantity, price, and item_category.
Item-level reporting, audiences, and product funnels become weak.
value
The value of the event, often used for purchase revenue or conversion value; when you send value, currency must be clear too.
purchase value can represent order revenue, but define whether it includes tax, shipping, and discounts, and confirm currency.
Revenue, ROAS, and imported ad value lose their base.
currency
Currency. Whenever value is used, currency must be clear; this is the base for standard reporting and Ads import interpretation.
USD, EUR, and GBP should not be mixed into one value without currency.
Multi-currency revenue and conversion value become hard to interpret.
transaction_id
The order deduplication field. It tells GA4 whether this is the same order.
Shopify order #1008 maps to purchase transaction_id.
Thank-you page refreshes or duplicate installs can double-count purchase.
Payload inspector
One broken purchase parameter can bend every later report
Do not only ask whether purchase fired. Break one test-order payload apart and inspect how transaction_id, value, currency, items, and sending paths can distort business decisions.
Payload inspection starts from a known order, not a report total. Write Shopify #1008 transaction ID, paid value, currency, and item line first, then compare GA4 field by field. This locates an ID, value definition, item mapping, or duplicate-sender gap.
The default bad example focuses on transaction_id. Predict the breakage first: one order cannot be reliably deduplicated or reconciled, so order and revenue counts can repeat. Repair order-ID mapping, not a report row.
Current bad example
Missing transaction_id
event_name: purchase
transaction_id: ""
value: 50.00
currency: USD
items: [{ item_id: "tumbler-20oz", quantity: 1 }]
What breaks
Thank-you page refreshes, duplicate tags, or multi-path sending can double-count orders and revenue, and reconciliation loses its anchor.
First fix
Map the Shopify order id or order name into transaction_id, then confirm DebugView, Tag Assistant / GTM preview, and next-day reports each show one purchase for the same test order.
Pass rule
DebugView, the Shopify order, and next-day reports all show the same order reference.
Do not do first
Do not import purchase into Google Ads or use it to explain ROAS.
The static default fix is a stable, non-empty transaction_id=TMB-1048 on purchase, with the same order appearing once across DebugView, next-day reports, and Shopify #1008. Until then, pause key events, Ads import, revenue, and product-performance reads.
For value, currency, items, or duplicate-sender cases, keep the same order as control. Repair one payload layer and rerun without simultaneously changing product, device, consent state, and release version.
30-minute event QA meeting
Use a five-part meeting path to decide whether the event can ship
This QA meeting is the complementary path for the event contract, evidence chain, and the go-live decision. The existing four-step test-order checklist below still runs one test order; neither path renames or replaces the other.
0-5 min
FocusChoose one chain to accept: core ecommerce events, a new custom event, server-side, or Measurement Protocol. Do not mix four paths into one “pass.”
EvidenceWrite the property, data stream, sender, test device, page/order scope, and release version so the meeting covers one chain only.
Action / outputOutput the QA chain boundary and owner; mark other senders as uncovered instead of using one path’s readout to accept another.
5-10 min
FocusConfirm event names and meaning: prefer recommended ecommerce events, keep a custom event only when a recommended event cannot express the action, and document deleted, internal-only, and mapped events.
EvidenceCompare the event dictionary, payload event_name, firing page, and business action; check that view_item, add_to_cart, begin_checkout, and purchase are not disguised by another name.
Action / outputOutput the keep/rename/delete/internal-only list; if naming is unresolved, do not mark a key event or enter Ads import.
10-18 min
FocusValidate items, value, currency, transaction_id, item identity, quantity, discount, and trigger timing field by field; treat a mismatch as a parameter issue first.
EvidenceUse the same Shopify test order to compare the DebugView payload, order details, sender path, and event time, recording missing, duplicate, empty, or definition mismatches.
Action / outputOutput a field-level repair list and retest condition; do not turn it into a revenue, product-performance, or demand conclusion before the parameter contract passes.
18-24 min
FocusRun the full evidence chain: DebugView, Realtime, test order, and next-day report. Seeing an event in Realtime is not a report-ready pass.
EvidenceKeep the test-device event order, Realtime property, Shopify order ID/transaction_id, next-day purchase/revenue readout, and processing delay.
Action / outputOutput pass, repair trigger/parameters/dedupe/delay first, or directional-only; without DebugView, order, or next-day proof, do not write “accepted.”
24-30 min
FocusGive the event a go-live decision: release, repair before reporting, directional-only, or block Ads import, with a responsible lead and next-check date.
EvidenceReview event_name, parameters, order uniqueness, consent/filter state, evidence chain, key-event/Ads boundary, and change log; every conclusion needs direct proof.
Action / outputWrite the status, owner, repair action, and next date into the event dictionary/QA record; this meeting does not rename or replace the four-step test-order checklist below.
Payload contract lab
Make one order’s fields clear before handing it to funnels or ads
The existing inspector shows which purchase fields can break. This lab brings valid JSON, a broken contrast, item scope, partial refunds, subscription boundaries, duplicate transaction_id, and a reviewable QA record into one practice. Everything is a classroom or authorized test reference and writes no data to GA4, Shopify, an ad platform, or a payment system.
Local field-QA record
Valid JSON is a field contract to verify, not production acceptance
Selecting, checking, filling, saving, and exporting keep a classroom record in this browser only. They do not send an event, create an order, issue a refund, change a subscription, edit a tag, change Google Ads, or alter consent.
Event-chain sandbox
Choose one event along a real shopper journey, then read the fields it must preserve, the order fact it can return to, and the business conclusion it cannot prove.
Payload focus
Read a stable, non-empty transaction_id, value, currency, items, coupon, shipping, tax, and sender, then compare them with the same Shopify order.
Order fact
Only when the order reference, payment state, value definition, and item lines can all be read back can later acceptance of this purchase be discussed.
What it cannot prove
One visible purchase does not alone prove net sales, no refund, ad incrementality, profit, or a usable Google Ads conversion.
JSON contrast contract
One reconcilable purchase
A 20oz tumbler is 49 USD with a 5 USD discount and 6 USD shipping, producing a 50 USD order value under the team’s stated formula. This practices field relationships only and does not confirm a real order is paid or revenue is accepted.
Readable valid payload
{
"event": "purchase",
"transaction_id": "TMB-1048",
"currency": "USD",
"value": 50.00,
"coupon": "WELCOME5",
"shipping": 6.00,
"tax": 0.00,
"items": [{ "item_id": "tumbler-20oz", "item_name": "20oz Tumbler", "item_variant": "sage", "price": 49.00, "quantity": 1, "discount": 5.00 }]
}Broken contrast payload
{
"event": "purchase",
"transaction_id": "",
"value": 50.00,
"items": [{ "item_name": "20oz Tumbler", "quantity": 1 }]
}Field mapping
Return item_id and item_variant to the Shopify product and variant, transaction_id to the same order reference, then state the value formula and treatment of coupon, shipping, and tax.
QA readback
Check fields and sender in DebugView or a test tool, the same Shopify order, and next-day reports. Mark any unread layer as unknown.
Boundary not to cross
A valid JSON shape is not proof of real payment, net sales, refunds, ad value, or profit.
Payload field QA gates
A check means the item is written into the classroom record. It does not mean an actual schema, pixel, Shopify order, refund, subscription, or ad setting was changed.
Payload fault exercise
A GA4 purchase for one order lacks item_id, value differs from the Shopify order, and the team is unsure about duplicate senders. Which next step preserves facts without creating a new production change?
Fillable payload QA record
Record only classroom aliases or authorized test references. Real customers, payments, addresses, admin screenshots, and access credentials belong only in an authorized working environment.
Payload official boundaries
Official pages checked: 2026-07-26. They describe current ecommerce-event, refund, deduplication, and validation boundaries. They do not replace readback for this store’s events, orders, refunds, subscriptions, consent, or ads.
Acceptance trail
QA is not only Realtime; keep an evidence chain
DebugView, Realtime, test order, and next-day review each prove a different layer. If one layer is missing, do not hand the data to funnels, audiences, or ad optimization yet.
DebugView
Use Google tag, Tag Assistant, GTM preview, or debug_mode to isolate the test device, then capture event order and parameters.
The test device is clear, event order makes sense, and required parameters exist.
Realtime
Confirm test traffic reaches the right property.
The stream and test device do not land in another property.
Test order
Save order ID, value, currency, items, purchase event time, and event-parameter record.
purchase appears once and matches the order system.
Next-day review
Standard reports, Explorations, and revenue definition explain the test order.
After processing delay, reports and DebugView do not contradict each other.
Cross-platform release checks
Pass the GA4 event before discussing Google Ads and Meta
A fired event only means collection started. Before it becomes a key event, Google Ads conversion, or Meta comparison point, keep backend records, fields, and stop rules.
GA4 event
Backend record / fields
DebugView event record, Events table, test device, and event time.
event_name, event_time, debug_device, items, value, currency, transaction_id
Release rule
First prove event name, trigger timing, and parameters. Before that, use it only to repair collection, not to judge the business.
Stop condition
The event is visible but parameters are missing, timing is wrong, device is unclear, or the order does not reconcile.
GA4 key event
Backend record / fields
GA4 Admin > Events / Key events state, marking time, responsible lead, and change log.
event_name, release_status, responsible_lead, change_log, report_scope
Release rule
Only QA-passed business actions become key events. After marking, state which reports can use it; it is not automatically an Ads conversion.
Stop condition
purchase still duplicates, value definition is unsigned, items is empty, or consent/filter state is unexplained.
Google Ads conversion
Backend record / fields
Google Ads conversion action, GA4 link, import state, value setting, and latest test order.
conversion_action, source, value_setting, attribution_setting, import_time
Release rule
Ads conversion should use a QA-passed key event or a clearly created conversion action. Keep the old conversion as a comparison before changing optimization.
Stop condition
GA4 purchase has not reconciled with Shopify, or value / currency / items would feed dirty data into bidding.
Meta event comparison
Backend record / fields
Meta Events Manager Test Events, event_name, event_id, content_ids, value, currency, and the same Shopify order.
event_name, event_id, content_ids, value, currency, order_id
Release rule
Meta does not need to copy GA4 naming exactly, but the same purchase needs explainable order ID, product identity, and value definitions.
Stop condition
GA4 item_id, Shopify variant, Meta content_ids, or Catalog item ID do not line up.
Official source boundary
Official docs prove the rule; they do not prove your Shopify order passed
Use official sources as a boundary table: they explain recommended naming, parameter specs, and what DebugView can do, but trigger timing, order reconciliation, and ad release still need your own test order.
Minimum activation check
If these gates fail, stay directional and do not enter ad optimization
A fired purchase is only the start. Before it becomes a key event, Google Ads conversion, or Meta comparison point, record order uniqueness, value definitions, product identity, proof, and the responsible lead.
purchase fires once
One Shopify test order creates one purchase in DebugView, Tag Assistant / GTM preview, and next-day reports.
transaction_id is unique and matches Shopify
transaction_id maps one-to-one to Shopify order ID / order name, and thank-you page refresh does not add an order.
value, currency, discount, and shipping definitions are clear
The revenue, discount, shipping, and tax formula for the same 20oz tumbler order is written into the event dictionary.
items includes item ID, name, price, and quantity
items is not empty, and item_id, item_name, price, and quantity explain the Shopify product and variant.
GA4 item ID maps to Meta content_ids / catalog key
The same product can be explained across GA4 items, Shopify variant, Meta content_ids, and Catalog item ID.
All four proof layers are saved
DebugView, Realtime, Shopify order, and next-day report all explain the same test order.
key event, Ads conversion, and Meta event states are recorded separately
GA4 key event, Google Ads conversion, and Meta event comparison each have a release state and stop condition.
Responsible lead, blocked move, and review date are recorded
The event dictionary states who fixes it, who accepts it, what stays blocked, and when to review again.
Test-order drill
Use one 20oz tumbler test order to accept three systems
The real pass standard is not that Realtime shows an event. One test order must explain the difference between GA4, Shopify, and ad imports.
Prepare test product, discount, shipping, currency, and expected order value.
One expected-value sheet for the test order.
Walk from product list to PDP, add to cart, cart, checkout, and purchase.
DebugView event-order record.
Reconcile purchase transaction_id, value, currency, and items.
GA4 purchase matches the Shopify order ID.
Confirm purchase appears once, with no duplicate GTM, Shopify app, or Customer events path.
One primary sending path and a duplicate-path note.
Check whether standard reports, Explorations, and revenue readout explain the test order.
A pass, fix-events-first, or directional-only decision.
Failure router
Find the broken layer before making a business call
One anomaly can come from real business, trigger timing, parameters, dedupe, consent, or processing delay. Route it before acting.
Route from a symptom, not a guess. Name the event, device or page, complete date window, and whether Shopify orders are stable before selecting a layer. Without scope, a purchase decline can be business or measurement.
The default symptom first compares real orders with GA4 purchase direction. Before clicking, write the cheapest counter-evidence and blocked move. The panel selects the next check; it does not declare a root cause.
GA4 purchase is much lower than Shopify orders
First check
Check whether purchase appears in DebugView, whether checkout/thank-you paths changed, and whether consent blocked collection.
Likely layer
Likely trigger timing, checkout boundary, consent state, or filtering issue.
Safe action
Place a test order and save event proof before calling it a business decline.
Avoid first
Do not cut ad budget first.
The static default route locks Shopify paid orders, then checks purchase count and transaction_id. If orders are stable while GA4 is missing, inspect trigger, payload, duplicate sender, consent, and processing delay. Do not label the gap a demand decline before evidence explains it.
Pass when one layer explains the difference and another evidence surface corroborates it. Otherwise narrow device, page, or release version and continue. No route alone proves attribution, incrementality, or profit.
Copyable lesson notes
Turn event QA into notes the next lesson can reuse
Do not leave this as a chat note saying the tag fires. After choosing the event boundary and failure route, copy the current pressure, first evidence, this-week action, blocked move, and review window.
The copy button assembles current selections, but the acceptance record first needs fixed facts: property time zone, test device, release version, #1008/TMB-1048, $48 USD, triggers and parameters for four events, next-day report, owner, and stop line. Dynamic choices cannot replace them.
“Copied” is interface feedback. Move the note into the task system, attach evidence links, and let another operator rerun the same order. If it cannot be reproduced, it remains unaccepted.
Current copyable version
These notes follow your selected event boundary and failure symptom. Copy them into task tracking, review, or the next Consent Mode analysis.
Not copied yet: copy feedback is not event acceptance.
Current pressure: GA4 purchase is much lower than Shopify orders
First evidence: use the 20oz tumbler test order, DebugView event record, Shopify order ID, and next-day reports to prove the chain.
Four-step chain: View product; view_item accepted: the 20oz tumbler PDP fires once, and items identity matches the Shopify product record.
Current event boundary: Recommended events; view_item_list, select_item, view_item, add_to_cart, view_cart, begin_checkout, purchase, and refund.
Acceptance layer: Event name layer; note line: event_name accepted: this purchase uses the recommended event name, not buy_success; DebugView and Events table match.
Payload inspection: Missing transaction_id; fix: Map the Shopify order id or order name into transaction_id, then confirm DebugView, Tag Assistant / GTM preview, and next-day reports each show one purchase for the same test order.
Payload lab: One reconcilable purchase; purchase: Read a stable, non-empty transaction_id, value, currency, items, coupon, shipping, tax, and sender, then compare them with the same Shopify order.
Payload QA record: 0/8. Complete field gates and the fault exercise before treating valid JSON as production acceptance.
Key event / Ads boundary: after event QA passes, decide whether to mark it as a key event or use it for a Google Ads conversion.
Meta comparison: the same purchase should explain GA4 item_id, Shopify variant, Meta content_ids, and order value differences.
ROAS / attribution boundary: do not explain ROAS or debate channel credit until purchase, value, currency, items, and transaction_id are verified.
Next article before activation: consent state and privacy measurement boundary.
This week's action: Place a test order and save event proof before calling it a business decline.
Blocked move: Do not cut ad budget first.
Review window: next-day reports, 7-day stability window, and the next Consent Mode lesson.
Static handoff: “US 20oz tumbler test order #1008 / TMB-1048, $48 USD. View_item, add_to_cart, begin_checkout, and purchase each fired once after the real state change. Purchase contains transaction_id, value, currency, and items for TMB-20-OZ × 1; DebugView, Shopify, and next-day reports reconcile.”
Stop line: “If any event is early or duplicate, or purchase lacks ID, value, currency, or items, do not build funnels, audiences, key events, or Ads imports. Repair one contract layer and rerun the same order.” The next lesson receives this accepted dictionary and evaluates consent visibility.
Completion check
The lesson is complete when one test order explains GA4, Shopify, Google Ads, and Meta differences; purchase fires once; value, currency, and items make sense; DebugView event records or logs are saved; and the event dictionary enters the change log.
Continue to privacy measurement