DEV Community: Montherion Labs

How to check Consent Mode v2 in the browser

Montherion Labs — Sun, 11 Oct 2026 16:09:25 +0000

Consent Mode lets Google’s tags adjust what they do to the visitor’s consent choices. Version 2 added two signals, ad_user_data and ad_personalization, to the original ad_storage and analytics_storage, and Google asks for them to use its advertising features with visitors in the European Economic Area. A banner that looks right can still send the wrong state. You can check it in Chrome DevTools.

The four signals

ad_storage: storage, such as cookies, related to advertising.
analytics_storage: storage related to analytics, such as visit duration.
ad_user_data: consent to send user data to Google for advertising.
ad_personalization: consent to personalized advertising.

1. A default before the measurement tags

The initial state must be set before Google’s measurement tags send anything. How to check it depends on the implementation:

With gtag.js: open the DevTools Console, type dataLayer (or the name of the data layer your site configures) and expand it. The consent default command should appear before the config command and before any event.
With a consent template in Google Tag Manager: the template can set the state without adding those commands to the dataLayer. Check the effective state in Tag Assistant instead.

2. The state after the banner

Accept or reject in your banner and check that the effective state matches the choice. With gtag.js, look for the consent update commands in the configured data layer; with Tag Manager templates, check it in Tag Assistant. Rejecting can keep a state that was already denied, and in basic mode the tags can stay blocked without loading. Before repeating with the other choice, close every private window or clear the site’s data, so the first choice isn’t remembered.

3. What GA4 requests carry

In the Network tab, filter by collect. When they are present, check two parameters:

gcs: G1 followed by one digit for ad_storage and one for analytics_storage (1 granted, 0 denied). G100 means both denied; G101, advertising denied and analytics granted; G110, the opposite; G111, both granted.
gcd: a longer code that also covers ad_user_data and ad_personalization, and whether each value came from a default or an update. Its presence alone doesn’t prove the four signals are configured.

In advanced Consent Mode, GA4 can send cookieless pings while analytics_storage is denied; denying only the advertising signals doesn’t imply the same behavior. In basic mode, the tags stay blocked until the corresponding consent is granted; rejecting it doesn’t enable them.

4. Tags that don’t follow Consent Mode

Consent Mode controls Google’s tags. The Meta Pixel and other tags only respect the visitor’s choice if your consent tool or tag manager blocks or configures them. After rejecting advertising consent, filter the Network tab by facebook.com/tr and check whether new requests appear that your setup should have blocked.

This guide is about checking the technical setup. It is not legal advice.

Scope

These checks examine outgoing requests visible in the browser. They do not establish what Google Analytics or Meta received, processed or counted, and they do not inspect server-to-server traffic or determine legal compliance.

Google Analytics and Google Tag Manager are trademarks of Google LLC. Meta is a trademark of Meta Platforms, Inc. Tracklint is not affiliated with, endorsed or sponsored by Google or Meta.

This article was written with AI assistance (#ABotWroteThis). It was first published on the Tracklint website: How to check Consent Mode v2 in the browser.

How to check a GA4 purchase event: a QA checklist

Montherion Labs — Thu, 08 Oct 2026 16:09:01 +0000

The purchase event feeds the ecommerce reports of Google Analytics™ 4 and, often, the conversions you use in Google Ads. A mistake here (a missing currency, a duplicate order, a value that counts shipping twice) is expensive and hard to see in the reports. This checklist shows what to look for and where.

What a purchase needs

Google’s ecommerce documentation lists these parameters for purchase:

transaction_id: a unique ID for the order. Required.
value: the monetary value of the event, as a number.
currency: a three-letter ISO 4217 code such as USD or EUR. Required when you send value.
items: the products bought. Required; each item must include an item_id or an item_name. price and quantity are recommended; if quantity is missing, GA4 uses 1.
Optional: tax, shipping and coupon, among others.

In GA4, value should be the sum of price × quantity of the items, without tax or shipping, which go in tax and shipping. If Meta records the order total, compare equivalent amounts before diagnosing a difference.

Where to see it in Chrome

Open DevTools (F12), go to the Network tab and type collect in the filter.
Place a test order. Look for a request to a /g/collect path with en=purchase among its parameters. With server-side tagging it may go to your own domain, and usually keeps that path.
Read the parameters: ep. marks text parameters (ep.transaction_id), epn. numeric ones (epn.value, epn.shipping), cu is the currency and pr1, pr2… are the items, with fields such as id, nm, pr (price) and qt (quantity) separated by ~: pr1=idSKU-1~nmT-shirt~pr59.9~qt1.
GA4 often sends several events in one POST request, one per line of the request body. Check the payload, not only the URL.

Tag Assistant helps you review which tags fire and their consent state. DebugView shows the events GA4 receives with debug mode on; consent and privacy controls can keep some of them from appearing.

Checklist

The purchase is sent only once per order and destination; reloading the confirmation page doesn’t send it again.
transaction_id is present and different for every order.
value is a number consistent with the purchase, without thousands separators or currency symbols. It can be 0 for a free order. A tracking plan may require value > 0 if it intentionally excludes zero-value orders.
currency is a valid three-letter code, the same one your store charges in.
Every item has an ID or a name, and value is the sum of price × quantity of the items.
No personal data in parameters or URLs: emails, names or phone numbers must not reach GA4.
The request goes to the right measurement ID (tid).
With a cookie banner, the purchase follows your consent setup (see the Consent Mode v2 guide).

Scope

Google Analytics and Google Tag Manager are trademarks of Google LLC. Meta is a trademark of Meta Platforms, Inc. Tracklint is not affiliated with, endorsed or sponsored by Google or Meta.

This article was written with AI assistance (#ABotWroteThis). It was first published on the Tracklint website: How to check a GA4 purchase event: a QA checklist.

GA4 and Meta Pixel purchases don’t match? Check what the browser sends first

Montherion Labs — Mon, 05 Oct 2026 16:15:45 +0000

It is normal for Google Analytics™ 4 and Meta Ads Manager to report different numbers of purchases and different revenue. Part of the gap comes from how each platform counts and attributes, which depends on settings you can review. Another part often comes from the tags on your site, and you can investigate it with Chrome DevTools before you spend hours comparing reports.

Differences you should expect

Attribution. Meta Ads Manager credits purchases to ads according to its attribution settings (for example, clicks or views within a time window). GA4 reports the purchases it receives and attributes them with its own model. The same purchase can count in one report and not in the other, or on a different day.
Consent and blocking. Visitors who reject cookies, use ad blockers or browsers that restrict tracking can stop one or both tags from sending data. With Consent Mode, GA4 may estimate part of what it doesn’t receive.
Server-side events. Purchases sent server to server, with Meta’s Conversions API or GA4’s Measurement Protocol, don’t appear in DevTools; the same purchase may also be sent from the browser.
Settings. Different time zones or currencies in the GA4 property and the Meta ad account move purchases between days or change the totals.

What to check in the browser

Place a test order with DevTools open (F12). In the Network tab, filter by collect to see GA4 requests and by facebook.com/tr to see Meta Pixel requests. Then check:

Each tag sends the purchase once per order. Count the purchase events per order and per destination (tid in GA4, id in Meta), including every line of batched POST requests. Two copies to the same destination point to a duplicate; the same order sent to two different properties or pixels may be intended. Common causes of duplicates: the tag installed twice (in the code and in Google Tag Manager), a trigger that fires on every load of the confirmation page, or a single-page app that sends the event again when the route changes. Reload the confirmation page too: if the purchase is sent again, every customer who reopens that page creates a duplicate. Depending on how each platform deduplicates, a duplicate can be dropped by one and counted by the other, which is itself a source of mismatch.
Both platforms identify the same order. A GA4 purchase needs a transaction_id (in the request, ep.transaction_id). The Meta Pixel has no required order field; many setups send the order number as order_id in the custom data (cd[order_id]). Deduplication with the Conversions API is a different thing: it pairs the Pixel’s eventID (sent as eid) with the event_id of the server event, for the same event name and the same pixel, and that ID doesn’t have to be the order number. To reconcile orders with GA4 one by one, you need a known correspondence between the IDs on each side.
Value and currency agree. Compare GA4’s value (epn.value) and currency (cu) with Meta’s cd[value] and cd[currency]. Typical causes of a gap: one tag includes tax or shipping and the other doesn’t, the value is sent as text with a thousands separator, or the currency is missing or different.
Each tag respects the consent applicable to it. With a cookie banner, check which tags send before and after the visitor accepts or rejects. Google’s tags follow Consent Mode, but the Meta Pixel only follows the visitor’s choice if your consent tool or tag setup blocks or configures it. If one tag waits for consent and the other doesn’t, their numbers will differ.
The confirmation page is reached. Payment methods that redirect to an external page (a wallet or a bank) don’t always bring the customer back to your confirmation page, so the purchase tags on that page never fire for those orders. Test each payment method you offer.

If this journey looks right

Check other journeys and devices too, the destinations the events are sent to, reception errors, filters, deduplication and processing delays, as well as attribution, consent, blocking and server-side events. Compare reports with the same date range, time zone and currency, and read each platform’s attribution settings before drawing conclusions.

Scope

Google Analytics and Google Tag Manager are trademarks of Google LLC. Meta is a trademark of Meta Platforms, Inc. Tracklint is not affiliated with, endorsed or sponsored by Google or Meta.

This article was written with AI assistance (#ABotWroteThis). It was first published on the Tracklint website: GA4 and Meta Pixel purchases don’t match? Check what the browser sends first.

How to check server-side tagging from the browser

Montherion Labs — Fri, 02 Oct 2026 16:09:20 +0000

With server-side tagging, your browser sends data to the configured tagging server endpoint. Verifying this connection from the browser is the first step to ensure your server container receives the events.

How to check the routing in DevTools

Open DevTools (F12), go to the Network tab and type collect in the filter.
Navigate your site to trigger a Google Analytics™ 4 event.
Check that the request URL matches your configured tagging server URL; this may use a custom domain (e.g., metrics.yourdomain.com) or a provider-assigned hostname.
Check the path. The request usually maintains the /g/collect path, indicating it is a GA4 payload.

What you can see in the browser

When the browser sends an event to your server container, standard GA4 requests generally use the same encoding as direct browser requests:

Parameters: You can see the event data included in that request, such as en (event name), tid (measurement ID), and custom parameters (ep. and epn.).
Consent state: When present, inspect gcs and gcd. Their presence does not prove that all consent types are configured or that server tags respect them; verify the effective state and server tag behavior.
Batches: GA4 often groups several events in a single POST request body.

What is not visible from the browser

The browser only shows what goes into the server. According to Google’s documentation, you cannot see from DevTools:

Which tags fire inside the server container.
What data the server modifies, redacts, or adds before forwarding it.
The final requests sent from your server to endpoints like Google Analytics, Google Ads, or the Conversions API.

To debug those server-side processes, you can use Preview mode of your server container in Google Tag Manager, as well as the server’s logs and other server tools.

Scope

Google Analytics and Google Tag Manager are trademarks of Google LLC. Meta is a trademark of Meta Platforms, Inc. Tracklint is not affiliated with, endorsed or sponsored by Google or Meta.

This article was written with AI assistance (#ABotWroteThis). It was first published on the Tracklint website: How to check server-side tagging from the browser.

How to check Meta Pixel event parameters in the browser

Montherion Labs — Wed, 30 Sep 2026 15:09:20 +0000

The Meta Pixel uses standard events to measure conversions and build audiences. Inspecting their parameters in the browser helps you check the values, currencies, and product data sent by the browser before relying on the Events Manager.

How to see Meta Pixel requests

Open DevTools (F12), go to the Network tab and type facebook.com/tr in the filter.
Trigger a standard event on your site, such as adding a product to the cart or completing a purchase.
Select the request and look at the Payload tab. Meta Pixel parameters are often encoded as cd[...] fields in the query string or form body.

Key parameters to check

Meta’s documentation defines specific parameters for standard events:

ev: the event name, such as Purchase or AddToCart.
cd[value]: the monetary value as a decimal number (e.g., 9.99), without currency symbols.
cd[currency]: a three-letter ISO 4217 code like USD or EUR.
cd[content_ids]: a JSON array of product IDs. cd[contents]: a JSON array of objects with id and quantity, optionally item_price.
cd[num_items]: the quantity of items.

Purchase requires value and currency.

Deduplication with the Conversions API

If you send the same events from the browser and a server (Conversions API), Meta needs to deduplicate them so they only count once.

Look for the eid (Event ID) parameter in the browser request.
For ID-based deduplication, send the Pixel eventID (serialized as eid) as the Conversions API event_id, with the same event name and pixel/dataset, within Meta’s deduplication window. Use a different ID for each distinct event. The browser alone cannot confirm server delivery or deduplication.
Standard events sent multiple times from the browser with identical data without an Event ID can inflate your conversion metrics.

Scope

Google Analytics and Google Tag Manager are trademarks of Google LLC. Meta is a trademark of Meta Platforms, Inc. Tracklint is not affiliated with, endorsed or sponsored by Google or Meta.

This article was written with AI assistance (#ABotWroteThis). It was first published on the Tracklint website: How to check Meta Pixel event parameters in the browser.

Catching a Meta Pixel consent bug with a CSV tracking plan

Montherion Labs — Sun, 27 Sep 2026 18:39:50 +0000

A consent banner can look correct while the Meta Pixel sends events before advertising consent is granted. This example compares a scripted sequence of requests with a written consent rule, then explains how to investigate the same problem in Chrome DevTools.

1. The plan: a CSV anyone can read

A tracking plan can be a plain CSV file. This example records event names, required parameters, value rules and consent conditions:

# consent_mode: advanced
platform,event,required,rules,count,consent,note
ga4,purchase,transaction_id;currency;value;items,currency is iso4217; value > 0; each item has item_id|item_name,once,analytics_storage,Order confirmation
meta,ViewContent,content_ids;value;currency,currency is iso4217; value >= 0,at_least_once,ad_storage,Product page
meta,AddToCart,content_ids;value;currency,currency is iso4217; value >= 0,at_least_once,ad_storage,Add to cart
meta,PageView,,,at_least_once,ad_storage,Every page

The consent column says which consent each event needs. For the Meta rows it is ad_storage: the Pixel should
not send those events while the visitor has not accepted advertising cookies. A plan written like this is useful
even without any tool: it is the checklist you hand to whoever implements the tags.

2. The bug

Our automated test opens journey.html?consent=denied&metarevoke=0: this sets Google's consent to denied and deliberately skips Meta's consent revocation. The page uses real tracking libraries; the harness intercepts collection requests locally. The page's default is:

gtag('consent', 'default', {ad_storage: 'denied', analytics_storage: 'denied',
  ad_user_data: 'denied', ad_personalization: 'denied'});

In advanced Consent Mode, Google tags can send cookieless pings while storage consent is denied. Google's consent commands do not automatically control the Meta Pixel.

The page calls PageView on load. The harness then calls ViewContent, updates Google's consent signals to granted to simulate acceptance, and calls AddToCart. The first two requests occur while ad_storage is denied; AddToCart occurs after it is granted.

For a manual check on a site with an interactive banner, inspect facebook.com/tr requests in DevTools and compare their timing with the page's consent updates. This demo has no interactive banner: reloading calls PageView, while the harness supplies ViewContent, the consent update and AddToCart. Reloading alone does not reproduce the full sequence.

3. Checking the journey against the plan

For this example, the plan requires the Meta Pixel events to occur only after ad_storage is granted. This is a rule of the site's implementation; Google's consent commands do not automatically enforce it for Meta.

Compare the sequence described above with that rule:

Event	Consent state when sent	Consent check
`PageView`	`ad_storage` denied	Fails
`ViewContent`	`ad_storage` denied	Fails
`AddToCart`	`ad_storage` granted	Meets this consent condition

To investigate a site manually, open DevTools before the journey, enable Preserve log and filter Network by facebook.com/tr. Identify the events and establish their order relative to the site's consent changes. A snapshot of the final consent state is not enough to determine the state when an earlier request was sent.

If the order cannot be established, record the result as inconclusive. An expected event that never appears is not observed; its absence does not demonstrate a successful consent check. Other requirements, such as parameters and event counts, need separate checks.

4. The fix

Make the Meta Pixel wait for the same decision as the Google tag. Two common ways:

With the Pixel code: call fbq('consent', 'revoke') before fbq('init', ...) when consent is denied, and fbq('consent', 'grant') when the visitor accepts.
With Google Tag Manager: require ad_storage in the Meta tag's additional consent checks and provide a trigger that fires after consent is granted. Updating consent alone does not automatically replay a previously blocked tag.

Repeat the check after the fix. Under this example's rule, no Meta event request should occur while ad_storage is denied. After consent is granted, perform the relevant actions and confirm that the expected events appear with the required parameters. Missing events still need investigation.

Scope

This checks what the browser sends during the journey you record. It does not verify processing inside Google
Analytics or Meta, server-to-server integrations (such as the Conversions API) or legal compliance.

Google Analytics and Google Tag Manager are trademarks of Google LLC. Meta is a trademark of Meta Platforms, Inc.
Tracklint is not affiliated with, endorsed or sponsored by Google or Meta.

This article was written with AI assistance (#ABotWroteThis).

Why GA4 DebugView is not showing events and how to fix it

Montherion Labs — Sat, 26 Sep 2026 03:21:08 +0000

Google Analytics™ 4 DebugView is the built-in tool to inspect events as they arrive. When events do not show up, the issue can be in the browser, in the network, or in the GA4 settings. This guide shows how to find the cause.

Check the browser in DevTools

Open DevTools (F12), go to the Network tab and type collect in the filter.
Perform the action that triggers the event. Look for a request to a /g/collect path.
Check the measurement ID: The tid parameter must match the measurement ID of the intended GA4 web data stream (e.g., G-XXXXXXXXXX).
Check the debug signal: Enable debug mode using Tag Assistant or debug_mode: true in the relevant gtag/GTM configuration. Inspect the outgoing debug signal, commonly _dbg=1. Its presence does not guarantee that the event will appear in DebugView.
Check the consent state: Inspect gcs and gcd when present. If analytics storage is denied (for example, gcs=G100), the event might not appear in DebugView depending on your consent mode configuration. G110 also indicates denied analytics storage. A cookieless ping does not establish DebugView visibility.
Check the network status: Ensure the request returns a 200 (OK) or 204 (No Content) status. An HTTP success response does not prove processing in GA4, especially when the destination is a tagging server. If something blocks it, like an ad blocker or browser privacy settings, it will not reach GA4.

Causes outside the browser

If the request leaves the browser correctly, Google’s documentation points to these causes within GA4:

Data filters: Check whether an active internal traffic filter excludes your test traffic. The developer traffic filter excludes debug traffic from reports while keeping it available in DebugView.
Selected device: In DebugView, verify that you have selected your specific testing device in the Debug Device drop-down menu in the top left corner.
Processing delays: While DebugView is designed to be real-time, there can sometimes be short delays.

Scope

Google Analytics and Google Tag Manager are trademarks of Google LLC. Meta is a trademark of Meta Platforms, Inc. Tracklint is not affiliated with, endorsed or sponsored by Google or Meta.

This article was written with AI assistance (#ABotWroteThis). It was first published on the Tracklint website: Why GA4 DebugView is not showing events and how to fix it.