Is X shaving my traffic?

[0d1n]

In ads dashboard on x I have about 100 clicks, but in server logs it's 60. Does X just making numbers up? It doesn't seems like bots - they didn't even visit website. I wouldn't be surprised considering it's CEO, but still interesting if anyone was stumble upon such problems.

 

[SelenaAylin]

The discrepancy is normal because X counts a click as soon as someone taps the ad, while your server only logs successful page loads; the missing clicks are usually from drop-offs, slow networks, blocked cookies, or tracking issues—not X “faking” the numbers.

 

[SpawneR]

The discrepancy is normal because X counts a click as soon as someone taps the ad, while your server only logs successful page loads; the missing clicks are usually from drop-offs, slow networks, blocked cookies, or tracking issues—not X “faking” the numbers.

Well 40% of them not loading the page is quite sus right?

 

[0d1n]

The discrepancy is normal because X counts a click as soon as someone taps the ad, while your server only logs successful page loads; the missing clicks are usually from drop-offs, slow networks, blocked cookies, or tracking issues—not X “faking” the numbers.

Service is small and fast, I doubt slow network is a thing. And it's logs from nginx, counting requests, so cookies and tracking also aren't a problem. I suppose even bots' clicks should lead to request to the website, not just stay at X dashboard. I'm curious if anyone else had this problem, because maybe there's something I'm missing (for example when I worked with Facebook, I didn't know they ALWAYS put their ref in url when redirecting).

 

[ads studio]

In ads dashboard on x I have about 100 clicks, but in server logs it's 60. Does X just making numbers up? It doesn't seems like bots - they didn't even visit website. I wouldn't be surprised considering it's CEO, but still interesting if anyone was stumble upon such problems.

A discrepancy between the clicks recorded by X Ads and the ones recorded by your server is really rather common. Even if the user's network is slow, they have tabs closed, or they are using a tracking blocker, X will still count the number of times they tap on a link. If a person is able to access your website, your server will just keep track of them. Look into your tracking configuration, page load time, and redirects before you assume the figures are overblown. Little problems can lead to larger variances than you would think.

 

[chewyzie]

In ads dashboard on x I have about 100 clicks, but in server logs it's 60. Does X just making numbers up? It doesn't seems like bots - they didn't even visit website. I wouldn't be surprised considering it's CEO, but still interesting if anyone was stumble upon such problems.

Its normal X counts every tap on the ad, but your server only sees real page loads. People close the tab before it loads, so the numbers wont match.

 

[ColdAkaza]

You’ll always see a drop because X logs the click the moment the user interacts, even if the redirect stalls or gets abandoned. Your server only records the hits that actually complete the request, so a 30 40% gap isn’t unusual on fast scrolling traffic.

 

[AcademicMan]

Another factor could be ad blockers or privacy tools that prevent the page from fully loading.

X still counts the initial click, but your server never sees it, which can explain why the numbers don’t align perfectly.

 

[0d1n]

Another factor could be ad blockers or privacy tools that prevent the page from fully loading.

X still counts the initial click, but your server never sees it, which can explain why the numbers don’t align perfectly.

You think some popular blocker might somehow blacklisted the website?

 

[AcademicMan]

You think some popular blocker might somehow blacklisted the website?

yepss some popular blockers and DNS lists flag domains aggressively, especially if they look ad heavy or new, so clicks get counted but the request never reaches you.

 

[Builder Dave]

X has the minimal bar for counting a click even if the user doesn't even get time to get redirected or for some reason blocks the action. But that still looks like a very large discrepancy. Maybe they are also shaving some of the traffic as well.

 

[TJworld377]

Ad blocker on client-side browsers could be the reason, simple as that

 

[0d1n]

Alright so my latest campaign has the similar problem. And don't give me adblock bs, logs are gathering before response and domain is legit.

107 visits from twi... x using in-house JS analytics and nginx logs shows 300 requests with x's parameter, meaning around 200 people are either not people, or using adblock. I suppose it's safe to say that the number 300 is actual number of clicks. It's just a bit under 30% of claimed by x. I don't mind higher price or lower results, just stop bullshitting.

My ads gathered in total 101 like, 2 reposts, 2 comments and 17 bookmarks, if anyone interested.

 

[XSMMDoctor]

@0d1n you're right to ignore the adblock excuse if you are analyzing raw nginx logs. Had a similar headache with X traffic last quarter.

Are you looking at "Clicks (All)" or "Link Clicks" in the dashboard? X is notorious for billing "clicks" which includes expands, profile visits, and even clicks on the retweet button. They bundle all that crap together to inflate the CTR.

Also, their t.co redirect system is buggy as hell. Sometimes their own verification bots hit the link immediately after a real user clicks it, which registers as multiple events on their end but only shows up as one clean request on your server if your nginx filters duplicates or if the bot cached the redirect. Honestly, X ads tracking is just garbage compared to Meta. You aren't missing anything, they just inflate the numbers.

 

[0d1n]

Are you looking at "Clicks (All)" or "Link Clicks" in the dashboard?

Thank you, friendly LLM, but I literally have "Link Clicks" in my screenshot. Guess technology is not here yet.

 

[VectorVelocityTraveler]

Whenever two systems count things differently, I trust neither

 

[The WP Nerd]

yeah nginx logs are the only real source of truth here, people always default to the adblock excuse when they don't know how servers work. what you are probably seeing is the mobile app webview behavior. when someone taps the ad on the X app, the click is registered instantly on their backend. but if the user fat-fingers it and hits back immediately, the app aborts the connection before the client even sends the initial request to your server. X still bills you for the link click because their internal redirect got triggered, but your nginx never sees a thing. tbh their app webview is just notoriously buggy and aggressive with tracking.

 

[Revenuestream1]

I had same issue before, mobile users especially cause this gap because of accidental taps or in app previews.