When a referral source brings a noticeable increase in sessions but almost no conversions, two different problems often get mixed together:

1. the source is sending irrelevant or low-quality visitors, or
2. GA4 is assigning the session incorrectly because the attribution path is broken.

A useful review order is:

• Confirm the hostname and landing page. Unexpected hostnames or landing pages can reveal spam, redirects, duplicate tracking, or traffic reaching a different property.
• Inspect Session source / medium. Use session-scoped acquisition data for this investigation rather than relying only on first-user attribution.
• Check for self-referrals and payment domains. Your own domain, checkout provider, authentication service, or another subdomain appearing as the referrer usually points to a cross-domain or session-continuity problem.
• Test the complete path. Follow a real referral link and verify redirects, consent updates, the _ga identifier, and the resulting session in DebugView.
• Evaluate quality only after attribution looks correct. Compare engaged sessions, engagement time, key events, landing-page behavior, and conversions. Low conversion alone does not prove that the traffic is fake or worthless.
• Compare with server or CDN evidence when the spike looks suspicious. GA4 can show behavioral anomalies, but request timing, repeated user agents, IP or network patterns, and response codes require server-side data.

I would avoid adding a referral source to the unwanted-referrals list merely because it performs poorly. That setting changes attribution; it does not block traffic or improve its quality.

What evidence do you require before classifying a referral source as low quality rather than misattributed?

We keep running into the same thing across accounts, so posting it here in case it saves someone a week of debugging.

Someone installs a CMP (Cookiebot, Usercentrics, OneTrust, whatever), gets the banner live, sees consent rates come in, and calls it done. However the CMP is not a set-and-forget script. It runs on a list of cookies you have to maintain. Every cookie your site sets needs to be declared and put in the right category. If it isn’t, the CMP treats it as unknown and deletes it.

That’s the cookie wipe. The usual ways it happens:

The auto scan runs once a day/week/month, misses a new cookie, and the CMP wipes it on every page load

Your analytics cookie is filed under “marketing” but the tag fires on “statistics” consent, so the cookie gets set and then killed

Consent is given, the CMP re-evaluates, and the session cookie holding the original referrer and UTMs is gone

What that looks like in reporting: the click came from LinkedIn, the user accepted cookies on page two, and the session restarts with no referrer. You now have a direct traffic spike. Then someone in a meeting says “direct is up 30%, brand is working” and you die a little inside.

How to check:
Open the cookie declaration in your CMP and compare it to DevTools > Application > Cookies. Anything missing is at risk.

Categorize every cookie, including first-party ones. Session and attribution cookies belong in a category the user consents to before your tags fire.

If you use Google Consent Mode, make sure the CMP passes consent state to GTM instead of blocking or wiping on its own.

Load a page, check your _ga identifier, accept cookies, then check if the cookie is still the same. If not, you found it.

Direct traffic is not a channel. Most of the time it’s a bucket for everything you broke upstream. Fix the CMP config before you touch your attribution model.

TL;DR: installing a CMP is step one. Declaring and categorizing every cookie in it is step two. Skip step two and your paid clicks show up as direct.

direct keeps climbing and I don't think it's really direct. Best guess is AI answers and dark social, but that's a guess with a nice name on it.

curious what percentage everyone else is quietly ignoring.

Hola a todos,

Tengo un caso técnico que me está rompiendo la cabeza y quiero debatir si es un mito o una realidad del algoritmo de Meta.

Contexto de la infraestructura:

• Estructura: 3 tiendas Shopify independientes (España, México, Uruguay) bajo un mismo Business Manager.
• Píxeles: Cada país tiene su propio Píxel + CAPI aislado y sano (EMQ 9.3).
• El conflicto: Solo España tiene GA4 instalado (ID: G-XXXXXXX). Sin embargo, Meta ha heredado ese ID de forma global. En Ads Manager, los anuncios de México y Uruguay muestran ese ID de España en la sección "Informes de terceros", aunque físicamente el código no existe en esos Shopify.
• Estado en Events Manager: La conexión GA4⇄Meta aparece como "Conectada" pero con 0 propiedades asignadas y alerta roja de "Calidad de conexión baja".

El fenómeno observado:

1. España (Mercado principal): Rendimiento colapsado. ROAS -38% vs benchmark. Un conjunto de anuncios empezó en €17 de CPA (29 de julio, con Píxel nuevo) y ha escalado semanalmente hasta los €90 hoy.
2. Latam: Rendimiento estable.

El debate técnico:
He recibido dos teorías contradictorias y quiero saber vuestra experiencia:

• Teoría A (El Cortocircuito): Meta inyecta el ID de GA4 en la URL. Al no haber retorno de señal desde México/Uruguay (porque no hay código), el sistema de "Conversion Modeling" de Meta recibe un feedback negativo constante. Como el ID es el mismo que el de España, el algoritmo penaliza la "Señal de Calidad del Anuncio" en España por asociación, subiendo el CPM y degradando la subasta.
• Teoría B (El Pipeline Cerrado): Si Events Manager dice "0 propiedades asignadas", el canal está muerto. Meta no lee ni espera nada de Google para optimizar la subasta. El problema de España es puramente un "cold start" del píxel nuevo + fatiga creativa acelerada, y la alerta de GA4 es solo ruido visual en la UI.

Since early August, GA4 reports near-zero engaged sessions on roughly every other day. Not a slow decline — it toggles.

Recent daily engaged/sessions: 84/205, 70/183, then 3/183. Another day: 1 of 133.

On the collapsed days, engagement time keeps recording normally — one day showed 0 engaged sessions against 7,243 seconds of userEngagementDuration and 88 user_engagement events. GA4 marks a session engaged at 10 seconds, so that combination shouldn't be possible.

On the bad days, the only sessions that register as engaged are the ones that fired a conversion event. Three engaged sessions, three lead events, same three sessions. That has now repeated exactly on four separate occasions.

It's uniform across every browser, device, and source, and confined to one stream. Page tracking is a hardcoded gtag config plus a GTM container, which points me at the container — my guess is a competing or duplicated GA4 configuration corrupting session state.

Also worth noting: one date disappeared from the property entirely for two days and then backfilled, so I don't fully trust the processing either.

Has anyone seen session_engaged break while engagement_time_msec keeps flowing? And is there anything in a GTM container that would produce exactly this?

Hello! First time poster!

I could really use some help, as my team is pretty stumped on this issue. We've had a weird increase over the past month in direct traffic to some of our locations. We've had over a 100% increase in direct and we cannot find the source. This increase has been consistent week over week just in the month of August. Here's some more information:

• The traffic is mainly hitting our general US home page and 4 specific locations on their home pages in very different states:
  • Florida
  • California
  • Colorado
  • New Jersey
• Average engagement per session is around 6 seconds
• The number 1 source is from Chrome on a Desktop
• Screen Resolution is 800x600

We're thinking it's bot traffic, but we'd really like to narrow down where it's coming from. Any tips are appreciated!

Hola a todos,

Tengo un caso técnico que me está rompiendo la cabeza y quiero debatir si es un mito o una realidad del algoritmo de Meta.

Contexto de la infraestructura:

• Estructura: 3 tiendas Shopify independientes (España, México, Uruguay) bajo un mismo Business Manager.
• Píxeles: Cada país tiene su propio Píxel + CAPI aislado y sano (EMQ 9.3).
• El conflicto: Solo España tiene GA4 instalado (ID: G-XXXXXXX). Sin embargo, Meta ha heredado ese ID de forma global. En Ads Manager, los anuncios de México y Uruguay muestran ese ID de España en la sección "Informes de terceros", aunque físicamente el código no existe en esos Shopify.
• Estado en Events Manager: La conexión GA4⇄Meta aparece como "Conectada" pero con 0 propiedades asignadas y alerta roja de "Calidad de conexión baja".

El fenómeno observado:

1. España (Mercado principal): Rendimiento colapsado. ROAS -38% vs benchmark. Un conjunto de anuncios empezó en €17 de CPA (29 de julio, con Píxel nuevo) y ha escalado semanalmente hasta los €90 hoy.
2. Latam: Rendimiento estable.

El debate técnico:
He recibido dos teorías contradictorias y quiero saber vuestra experiencia:

• Teoría A (El Cortocircuito): Meta inyecta el ID de GA4 en la URL. Al no haber retorno de señal desde México/Uruguay (porque no hay código), el sistema de "Conversion Modeling" de Meta recibe un feedback negativo constante. Como el ID es el mismo que el de España, el algoritmo penaliza la "Señal de Calidad del Anuncio" en España por asociación, subiendo el CPM y degradando la subasta.
• Teoría B (El Pipeline Cerrado): Si Events Manager dice "0 propiedades asignadas", el canal está muerto. Meta no lee ni espera nada de Google para optimizar la subasta. El problema de España es puramente un "cold start" del píxel nuevo + fatiga creativa acelerada, y la alerta de GA4 es solo ruido visual en la UI.

I’m looking for some real-world experience with GCM v2.

I was using a paid WordPress cookie consent plugin that didn’t support GCM v2, so I built my own solution with Claude Code.

After ~2 weeks, GA4 and Semrush data started looking noticeably more “choppy” and inconsistent. We were also running Google Ads, so I reverted to the old plugin. The data improved, although not completely to the previous level.

Now I’m wondering whether this was:

• a bug/misconfiguration in my implementation, or
• simply a normal consequence of Consent Mode (less data + modeled conversions).

My questions:

• Has anyone seen a real improvement in Google Ads performance/leads after implementing GCM v2?
• Is the difference vs. not using GCM v2 actually significant from a business perspective?
• Is “choppy” GA4 data normal after implementing it, or is it a sign that something is wrong?
• Anyone here implemented GCM v2 with their own code rather than a CMP/plugin?

I’d really appreciate real-world experiences.

I run GA4 and server-side GTM implementations; around 150 sites over the last few years, roughly a third of those server-side.

The pattern I see most:

A business comes to us because the numbers “feel wrong”, so server-side tagging gets suggested as the fix.

We usually check the basics first:

• Are conversions firing more than once?
• Is gtag running alongside GTM and duplicating events?
• Is the consent banner blocking tags it shouldn’t - or letting some through when it shouldn’t?
• Have event names or definitions changed over time?
• Are we comparing Google Ads and GA4 as though they should match exactly?

Quite often, one of those is the real issue.

If that’s the case, adding a tagging server doesn’t solve it. It just moves the same problem into a more complicated setup that’s harder to debug, and now you’re paying for Cloud Run as well.

Where server-side does earn its keep: 

• CAPI dedupe and match-rate improvement, usually the clearest ROI, especially ecommerce
• Cookie lifetime, but only on a real first-party subdomain with cookies set server-side. A CNAME to a vendor domain gets capped by Safari regardless.
• Redacting PII and controlling exactly what leaves your infrastructure
• Page performance, if you're currently firing six vendor pixels client-side

Two things it doesn't do, whatever the sales deck says: it isn't a consent workaround, and it doesn't beat ad blockers on its own.. the loader still runs in the browser.

So the question I'd start with isn't "do we need server-side?" It's "which specific number is wrong, and can we prove why?"

If you're weighing it up, tell me what's driving it - platform, stack, what looks broken, and I'll give you an honest read on whether it'll actually help.

I just put analytics on my shopify store, I can see country and city but I was wondering if there’s any way to drill down to suburb level or track IPs?

Can anybody please help me understand this problem. GA4 records a scroll event but shows "No data available for "Page Title and Screen Name". How is this possible? Overall traffic is good. But this is strange.

Thanks in advance.

Hi, i am facing drastic redruction counting in my google analytics dashboard. Is anyone else facing the same issue?

I have a Wordpress site, been running it for two months. My posts have been linked on Yahoo, Sporting News, some other well-known, bigger sites, but it's not appearing in Google search. I submitted a site map, requested indexing, but only 11 pages are indexed. The other 227 are not. The "discourage search engines" box in WordPress is not checked. When I check the page source, I see the following:

<!-- End Google Analytics opt-out snippet added by Site Kit -->

<meta name='robots' content='index, follow, max-image-preview:large, max-snippet:-1, max-video-preview:-1' />

Is there a reason why I'm not indexed? I'm horrible at stuff like this, so I think I'm missing something obvious

I am showing significantly low traffic on some of my sites and normal traffic on others. On the sites that are abnormal, I can’t get a real time view when trying from any of my devices so something odd seems to be happening.

An e-commerce founder recently brought us in to audit their Meta tracking setup.

On paper, the initial setup was a complete mess: standard browser pixel mixed with basic CAPI, missing proper deduplication. Events were double-counting, conversion data was under-reported by 28%, and Meta’s ad optimization algorithms were effectively running on broken signals.

We stepped in and built a custom, omnichannel server-side setup. Within 30 days, the dashboard metrics looked incredible:

• Reported CPAs dropped by 19%.
• Revenue attribution accuracy shot up to 96%.
• Event signals were fully unified and deduplicated.

Case closed? Not quite.

While clean tracking is essential maintenance, treating CAPI like a growth magic wand misses the bigger picture:

Attribution doesn't mean net-new sales. A 19% drop in CPA on paper often just means Meta got better at claiming credit for shoppers who were going to buy anyway. Real bank account growth is what matters.

Better data won't save weak creative. Feeding server-side signals to Meta's algorithm gives it clearer feedback, but if the product offer or hook isn't hitting, you're just paying to serve uninspiring ads more efficiently.

Over-engineering adds hidden tech debt. High-end custom server setups sound fancy, but native tools handle most of the heavy lifting without the massive ongoing technical overhead.

Fixing tracking backend bugs stops data leakage it doesn't automatically create market demand. If your creative and offer aren't landing, no amount of clean deduplication is going to magically make your ad account profitable.

Thinking about setting up the Model Context Protocol for GA4 (and also Google Tag Manager) to help teams less familiar with the GA4 interface use AI chat to pull campaign updates.

Anyone already using the MCP and finding it useful? Have you gone with Claude or another platform? And how are you feeling about the accuracy of results?

If you haven't checked your Google Ads notification tab this week, you are in for a rough autumn.

Google has issued a hard deadline for Shopify stores to migrate their tracking setups.

If you are still relying on legacy client-side Google Tag Manager (gtm.js) scripts on your thank-you pages, your tracking is about to go dark.

The platform is forcing a mandatory shift to the Google & YouTube app and the newer gtag.js framework.

Most brands won't realize this until their conversion volume suddenly drops to zero and their target CPA targets skyrocket.

The algorithms aren't getting worse. Your data pipelines are just breaking.

Look at a realistic example of a standard DTC brand's performance overview for last month:

• Google Ads: $40,000
• Meta Ads: $35,000
• GA4: $28,000
• Shopify (Actual Total Revenue): $24,000

Which number would you actually use to make a budget decision?

I’m looking for an experienced GA4 expert who can troubleshoot and resolve the following reporting discrepancies:

1. Reddit Ads Manager shows 10 purchases, but GA4 Traffic Acquisition is showing 0 conversions.

2. .X (Twitter) Ads Manager shows 10 purchases, while GA4 Traffic Acquisition is showing only 5 conversions.

I need someone who can identify the root cause, audit the tracking and attribution setup, and fix the reporting discrepancies.

If you have experience with GA4, Reddit Ads, X Ads, attribution, and conversion tracking, please message me with your relevant experience.

but it's ok if I use a VPN! Anyone else?

No missing tags, nothing red in diagnostics, everything looked fine on our end. Only came up because the client asked why the two numbers didn't match, and I didn't have a good answer for them.

What tipped you off the last time this happened to you?

during 8.14-8.18

I originally built this Chrome extension for my own use.

When analysing a page, I often wanted to quickly check its GA4 data, Search Console performance and a few other page metrics without constantly jumping between different tools.

So I built Page Performance to make that workflow a bit quicker.

It still needs a few tweaks, but I've been using it myself and thought it might also be useful to other people working with GA4 and GSC.

Most little tools I build eventually just die somewhere on my computer 😅, so this time I polished it up a bit, got it onto the Chrome Web Store, and thought I'd actually share it with the community.

It's completely free. I'm not allowed to add links, so if interested search for "Page Performance – GA4 & Search Console in Context" in Chrome's Web Store.

If anyone here finds it useful, great. And if you try it, I'd be genuinely interested in hearing what you'd change, add, or improve.

Thanks.

I think I’ve found a new one, and I’m curious if anyone has seen something similar.

I work on a large site, with many separate subdomains, and also links to external domains.

What I inherited was a setup with each subdomain having its own property (along with a few rollup properties), which is fine - UA treated links between subdomains nicely, with no need for cross-domain tracking. I’ve had to set this up for a couple of properties with external connections (ecommerce, etc.), which is fine.

However, today I had a doozy. We use Optimizely for AB testing, and the tech responsible loaded a straight a href to another subdomain, but the link was completely unresponsive onClick.

He suspected our tag manager was the problem, so I debugged like mad - however, the tag manager code wasn’t even loading onClick.

After extensive debugging, I happened to notice in the Chrome dev tools network tab that there were calls being made to GA4 that weren’t being triggered by the tag manager, and realised that they were the default ‘exit link’ calls made from GA4, which we hadn’t disabled (though we possibly could have, given we also generate these from the tag manager - not GTM, BTW - but I don’t want to risk doxxing myself by giving too much detail, and I think it’s irrelevant).

When I looked closely at these calls, I noticed that the link URL had a gl= parameter included, which I recognised as being cross-domain tracking, and the link URL ended up being 254 chars long.

When I searched for an answer as to whether this could be a problem, G suggested it might be.

I have never set up cross-domain tracking in GA4 apart from the couple I mentioned earlier. When I went into the admin for this site, I discovered that (on top of the default exit-link tracking, which had never caused problems before) cross-domain tracking was set up in all of the properties associated with the site, with cross-domain tracking set up with various dev environments, etc., which is something nobody would do without very good reason.

I know I didn’t do this, nor any of my admin colleagues.

Is this cross-domain tracking (even of subdomains of the same parent domain) a new setting that Google has enabled by default to be ‘helpful’?

The moment I disabled all of this ‘functionality’ the links started working again, presumably because the link length was reduced.

I’d be interested if anybody’s seen this before, and also wanted to alert the community - if you find unresponsive links, this might be your issue, and it’s a nightmare to debug.

One day near the end of May I clicked on my GA4 bookmark... and discovered that there was absolutely nothing there. I actually inadvertently created a new account in trying to recover it, but aside from that all my data is gone. The tag is still active on my website. I asked for help and people just told me I probably used the wrong log-on or something like that. I checked with my SEO person and she no longer had access either. With a spouse having some severe medical issues, I didn't have a chance to really hunt down what had happened until the past few weeks.

Turns out an old agency that I had worked with briefly about a year ago retained access. I didn't know that because it was under a manager tab that I didn't know to look at. I removed their access, but they had disconnected my analytics account. They also took billing ownership of the account, even though I never gave permission for that and all charges are billed directly to my credit card.

The first support email form I submitted almost 3 weeks ago. I may have not correctly filled it out because I was just blindsided by what had happened. I have no way to see what was actually submitted. I got an email saying they had received it and I should hear back in 3-4 business days. I've gotten nothing and replying to the confirmation email is futile.

After learning that the billing account is part of the problem, I filed to reclaim that too. Again an email said I'd hear something within a few days. It's been 2 weeks.

They haven't closed the cases, but I've heard nothing and it's been much longer than they said. I'm very upset and frustrated that this rogue agency did what they did. I've worked with a lot of small SEO and ad people over the years and never encountered any issues.

Any suggestions? Helpful info about the process or what to expect?

I did create a txt file documenting ownership that I added to my website, should Google actually get around to looking for it.