Analytics deep dive

The full reference. Read it when you're ready to go deeper, set up tracking yourself, or audit an agency's work.

1. Event design is more important than the tag

A perfectly installed tag can still send terrible information.

The normal ecommerce progression is:

view_item_list
select_item
view_item
add_to_cart
view_cart
begin_checkout
add_shipping_info
add_payment_info
purchase
refund

Google recommends these standard names because they automatically populate ecommerce reporting when the required parameters are supplied. (Source: Google, GA4 recommended events)

The trigger must describe the actual outcome:

• Clicking Add to Cart is not necessarily add_to_cart. Shopify successfully modifying the cart is add_to_cart.
• Clicking Checkout is not necessarily begin_checkout. Shopify opening or creating checkout is begin_checkout.
• Submitting a newsletter form is not necessarily a Lead. Klaviyo accepting the signup is a Lead.
• Arriving on a payment page is not a Purchase. Shopify confirming a paid order is a Purchase.

That distinction alone prevents a large percentage of bad analytics.

Every commerce event should normally contain:

• Stable product and variant IDs
• Product name and SKU
• Price
• Quantity
• Currency
• Subscription versus one-time purchase
• Applicable discount
• Offer, source, or button location when useful
• An item array in the format required by the destination

For Purchase, include a unique, nonempty transaction_id. GA4 uses that ID to minimize duplicate web purchases. Accidentally using an empty string or reusing an ID can severely distort reporting. (Source: Google, GA4 transaction ID guidance)

2. One owner per event, per destination

This is the most important architectural rule.

One event can be sent to several destinations. But each destination should have one agreed owner for that event. For example:

• Shopify may send Purchase to GA4.
• GA4 may import that Purchase into Google Ads.
• Shopify may separately send Purchase to Meta.
• Shopify may separately send Placed Order to Klaviyo.

That is fine. The problem is when Shopify, the storefront, GTM, and a custom server webhook all send GA4 Purchase independently.

Common duplication sources:

• Hardcoded tag plus GTM
• Shopify app pixel plus custom pixel
• Browser purchase plus server purchase with different IDs
• Thank-you page Purchase firing again on refresh
• Two Google Ads Primary Purchase conversions
• An agency adding a second Meta Pixel
• A React component registering the same listener twice
• A webhook retry generating a new event ID

Shopify itself warns that adding additional Meta pixel code beside its integration can produce duplicate or incorrect reporting. (Source: Shopify, Meta Pixel guidance)

3. Browser, server, and native events are different tools

Server-side tracking is not automatically "better." It is better for some facts, such as a confirmed payment. It is worse for others, such as whether someone actually saw a product section.

It also does not bypass consent. Server-side tagging can improve control and performance, but consent, field filtering, and deduplication still have to be implemented deliberately. (Source: Google, server-side tagging)

Use server facts for: paid orders, refunds, cancellations, subscription state, CRM activity, Klaviyo list and profile operations.

Use browser facts for: page and product views, product-list impressions, button and promotion interactions, campaign and referrer context, cart behavior.

4. Know your different IDs

These IDs solve different problems and should never be conflated.

For Meta browser and server deduplication: same event, same event name, same event ID.

For GA4 Purchase deduplication: the same stable transaction ID.

A retry should reuse its original event ID and original event time. It should not manufacture a fresh ID, because that makes the retry look like another customer action.

Never put email, phone, or a customer's name inside any of these IDs.

5. Attribution means "credit," not causation

Suppose someone:

1. Sees a Meta ad Monday.
2. Clicks a Google ad Tuesday.
3. Returns directly Wednesday.
4. Purchases once.

Shopify reports one order. GA4 may credit Google. Google Ads may credit Google. Meta may also credit itself based on its click and view attribution rules.

That does not mean three purchases happened. It means three systems evaluated one purchase using different rules.

The three major attribution ideas:

• First touch: how the customer originally found you.
• Last touch: their most recent qualifying marketing visit.
• Platform attribution: whether Meta or Google considers the order attributable under its own window and model.

Attribution is not incrementality. A platform claiming a purchase does not prove that the advertisement caused it. Proving causation requires holdouts, lift tests, or carefully designed experiments.

• Shopify for total orders, revenue, and refunds
• GA4 for customer journeys and channel comparison
• Meta and Google for campaign delivery and bidding
• Incrementality tests for "would this sale have happened anyway?"

6. UTMs are labels; click IDs are stronger joins

A well-tagged external URL usually includes:

• utm_source: who sent the traffic
• utm_medium: channel type
• utm_campaign: stable campaign name
• utm_id: stable campaign ID
• utm_content: creative or ad variation
• utm_term: keyword, audience, or ad set where useful

Google recommends consistent campaign parameters and warns that capitalization differences fragment reporting. Meta, meta, and META can become separate rows. (Source: Google, campaign URL guidance)

Rules:

• Use lowercase.
• Do not rename a campaign mid-flight.
• Preserve UTMs through redirects.
• Never include email or other personal information.
• Never place acquisition UTMs on internal links.

That last rule matters. If someone arrives from Meta and then clicks an internal homepage button marked utm_source=homepage, you may overwrite the actual Meta attribution.

Click IDs include:

• gclid, gbraid, wbraid for Google
• fbclid and derived Meta click context
• ttclid for TikTok
• msclkid for Microsoft

Google Ads auto-tagging automatically appends a GCLID so an ad click can be connected with Analytics and later conversions. (Source: Google Ads, auto-tagging)

7. Cross-domain tracking is crucial for headless Shopify

When the journey crosses from a marketing site into Shopify checkout, analytics without continuity can think:

• One person on the site became another person on Shopify.
• Shopify referred the customer to itself.
• The original Meta or Google source disappeared.
• The purchase was Direct or Shopify Referral.

Cross-domain measurement passes the appropriate measurement identity between domains. You must also ensure redirects preserve the linker and that checkout and payment domains do not become false referrals. (Source: Google, unwanted referrals and cross-domain measurement)

Test every hop: the marketing site, the shop subdomain, Shopify checkout, payment-provider redirects, thank-you and order-status pages, and return visits.

8. Consent is purpose-based

Think in purposes, not only vendor names:

• Necessary: cart, checkout, authentication, fraud and security
• Analytics: GA4, Clarity
• Advertising: Google Ads, Meta
• Preferences: language and currency
• Sale/share or targeted-ad opt-out
• Email consent
• SMS consent

Email consent is not analytics consent. Analytics consent is not permission to send email. Giving a phone number for delivery is not SMS marketing consent.

Google Consent Mode carries the visitor's choice to Google; it does not obtain consent or decide what is legally required. Google currently distinguishes states such as analytics_storage, ad_storage, ad_user_data, and ad_personalization. (Source: Google, Consent Mode)

Good implementation behavior:

1. Determine the default consent before tags start.
2. Load only permitted vendors.
3. Update vendors if the customer changes their choice.
4. Carry the consent state into checkout and server processing.
5. Respect applicable sale/share opt-outs and GPC.
6. Fail closed when consent is unknown.

This is an implementation framework, not legal advice. Requirements differ by state and customer location.

9. Raw versus hashed customer data

Raw email or phone should not appear in:

• Ordinary GA4 event parameters
• Custom dimensions
• URLs or UTMs
• Page titles
• Search terms
• Event names
• Debug logs
• Event IDs
• Order-attribution notes visible to multiple tools

Google prohibits recognizable PII in normal Analytics collection. Its redaction setting is only a best-effort backup, not permission to send it. (Source: Google Analytics, PII guidance and data redaction)

Meta can receive email and phone through its designated matching fields. Those fields are handled according to Meta's rules and normally hashed. But hashing is not anonymization and does not remove consent or privacy obligations. (Source: Meta Business Tools Terms)

Correct structure:

• Actual email goes to the Shopify or Klaviyo customer record
• The GA4 event says "newsletter signup succeeded"
• Meta's matching email goes in the designated, consented matching field
• The internal ledger holds order and event identifiers, not contact information

URLs deserve special suspicion because they spread into analytics, referrer headers, server logs, session recordings, and other vendors.

10. More tags do not mean better measurement

Every browser tag can add network requests, JavaScript download and parsing, main-thread work, cookie and storage work, event listeners, memory, privacy surface, and another place that can break.

async means "do not block HTML parsing." It does not mean "free." The script still competes for bandwidth and CPU, especially on mobile.

A sensible loading order:

1. Necessary first-party site functionality
2. Lightweight consent and campaign capture
3. Main image and content
4. Google analytics after the first paint
5. Paid-social vendors later
6. Session recording later still
7. Email, reviews, and cart code only when relevant
8. Release a needed vendor immediately if the customer shows real commerce intent

A tag can also hurt INP (responsiveness) after the page looks loaded. LCP is not the only performance concern.

Before adding a vendor, ask:

• What decision will this data change?
• Does another tool already provide it?
• What exact event does it own?
• What customer data can it access?
• When will it load?
• How will it be removed?
• Who owns its account?

11. Direct gtag versus GTM

GTM is not inherently bad. It is valuable when a larger organization needs many regularly changing integrations, marketing-controlled deployments, complex testing, multiple environments, and strong container review.

Its dangers:

• Invisible dashboard changes
• Old tags lingering
• Agencies adding duplicates
• Broad DOM scraping
• Changes going live without code review
• Extra permissions and complexity

Direct code is better when the tag set is small and stable, developers version and test the behavior, performance matters, and you want changes reviewed alongside the website code.

12. Understand the reporting terms

These are not interchangeable:

• Event count: how many times something fired.
• Users: estimated browser or user identities, not necessarily unique humans.
• Sessions: groups of activity, not necessarily one complete shopping journey.
• Key event: an event marked important in GA4.
• Conversion: often an Ads optimization or reporting action.
• Attributed purchase: a platform gave itself credit.
• Observed purchase: directly measured.
• Modeled purchase: statistically estimated because direct measurement was missing.
• Event coverage: what percentage of eligible orders reached a destination.
• Match quality: how well a platform can associate an event with an account.
• Revenue reconciliation: whether values match under the same definitions.

High Meta Event Match Quality does not prove the Purchase trigger is correct, that events are not duplicated, that revenue is accurate, or that Meta caused the purchases. It speaks primarily to Meta's ability to match the event information you supplied.

GA4 attribution and modeled key-event data can keep updating for days. Google says attributed conversion data can change for up to 12 days. Avoid diagnosing campaign performance from today's incomplete report. (Source: Google, modeled key events)

13. Know how to test every hop

A tag's journey has four distinct proofs:

Application emitted it
Browser or server attempted it
Vendor accepted it
Report processed and attributed it

These are not the same. Use:

• Browser DevTools Network: did the request leave?
• Console or debug logger: did the site emit one canonical event?
• GA4 DebugView and Realtime: did GA4 receive it?
• Meta Events Manager Test Events: browser or server? Deduplicated?
• Meta Pixel Helper: did the browser pixel load and fire?
• Klaviyo profile activity: did the event reach the correct profile?
• Shopify order: what actually happened financially?
• Shopify order details: did attribution reach the order?
• Session recording tool: did the session receive the correct safe tags?
• Server logs: accepted, rejected, retrying, or verified?

A 200 network response does not always mean the vendor interpreted every field correctly. Debug and validation tools matter.

14. The minimum test matrix

Do not test only desktop Chrome with every cookie accepted. Test:

• Desktop Chrome
• iPhone Safari
• Meta and Instagram in-app browser
• Direct visit, Meta-tagged visit, Google-tagged visit
• Analytics accepted, advertising accepted, reject all
• Returning visitor with saved consent
• One-time order, subscription order, mixed cart
• Valid discount, invalid discount
• Failed and successful Add to Cart
• Abandoned checkout
• Successful paid order
• Refund
• Back button and refresh
• Accelerated payment wallet, if supported

For every controlled order, record: order ID, timestamp, device and browser, consent state, source and campaign, expected events, actual events, value, currency, items, browser or server source, and the deduplication result.

15. Ratios that reveal broken tagging

Purchase coverage: distinct GA4 transaction IDs ÷ eligible Shopify paid orders. This measures capture, not attribution.

Duplicate factor: raw Purchase events ÷ distinct transaction IDs. If it's materially above 1, investigate refreshes, multiple owners, or retries.

Meta deduplication coverage: browser/server pairs with the same event name and ID ÷ expected pairs.

Revenue reconciliation: destination purchase revenue ÷ Shopify revenue under the same definitions. First align gross versus net, discounts, tax, shipping, refunds, currency, time zone, and order eligibility.

Funnel rates:

• Product viewer to Add to Cart
• Add to Cart to begin checkout
• Begin checkout to Purchase
• Session to Purchase

Use distinct users or sessions consistently. Raw event count is usually the wrong denominator because one person can add several products.

Attribution health. Watch for:

• A sudden increase in Direct
• Shopify or checkout referrals
• (not set) campaigns
• Lost click IDs
• Campaign names split by capitalization
• Mobile-only drops
• Meta browser events without matching server events
• Purchases missing product IDs

Compare against a four-week, same-weekday baseline, and annotate deployments and campaigns.

16. Source of truth by question

17. Case study: the Lezzet setup, in operator language

Lezzet runs a headless storefront (a custom site) in front of Shopify checkout. This is its target tracking architecture:

• No GTM container.
• One direct Google runtime.
• Shopify owns checkout and financial conversion facts.
• Google Ads has one Primary Purchase import.
• Shopify owns Meta's standard commerce events (AddToCart, InitiateCheckout, Purchase).
• Lezzet sends its own custom cart signals to Meta, with browser/server deduplication.
• Only successful acquisition forms become Leads.
• Raw email and phone are removed from analytics payloads.
• Campaign attribution follows the cart into Shopify.
• Google, Meta, Clarity, and Klaviyo load in stages.
• Klaviyo receives email data through its intended profile and form system.
• Klaviyo's native Shopify integration owns Placed Order, so Lezzet doesn't replay it.
• Cloudflare browser analytics is unnecessary.
• TikTok stays dormant.
• Optional extras (a Meta paid-purchase signal, GA4 refunds) stay off until controlled live validation.

Ten questions to ask before approving any tag

1. What exact business action does it represent?
2. Does it fire on a click, an attempt, or a confirmed outcome?
3. Who is the single owner for this event at this destination?
4. Is it browser, server, native, or intentionally paired?
5. What stable event or transaction ID prevents duplicates?
6. Which parameters are required, and where do they come from?
7. Could email, phone, or sensitive data enter the payload or URL?
8. Which consent purpose permits it?
9. When does its JavaScript load, and what does it cost on mobile?
10. How will we prove it arrived once and reconcile it to Shopify?

If an agency or developer can't answer these ten questions, they shouldn't add the tag.

The cheat sheet

• One financial truth: Shopify.
• One owner per event per destination.
• Measure confirmed outcomes, not optimistic clicks.
• Use vendor-recommended ecommerce events.
• Keep event IDs, transaction IDs, click IDs, and customer IDs separate.
• Preserve external UTMs and click IDs.
• Never use acquisition UTMs internally.
• Cross-domain continuity is mandatory for headless checkout.
• Raw PII never belongs in normal analytics events.
• Hashing does not equal anonymity or permission.
• Server-side does not mean consent-free.
• Browser and server copies need intentional deduplication.
• More tags often mean worse data and a slower site.
• Platform attribution is not causation.
• A network request is not proof of processed reporting.
• Compare distinct orders, not raw Purchase event counts.
• Test consent, mobile, in-app browsers, discounts, subscriptions, and refunds.
• Audit every tag after major releases and at least quarterly.
• If nobody owns a tag, remove it.