I know other have posted on this but I can't seem to find a good solution to help minimize the massive click discrepancies I see between fb (website clicks) and my tracker (
Are you cloaking / blanking the referrer? Try testing with it off if you are.
I had roughly a 50% click loss with Prosper's built in cloaker / blanker.
using a cloaker but it's only redirecting 5% of the clicks.
A real 50% click discrepancy on FB is not normal.
But, it is very common for people to misread FB's metrics and think more clicks should be going to their site than actually do.
I see you mention website clicks specifically, which suggests you are looking at the right metric...
But in any case, you should pull up a report showing impressions, clicks and every type of action available. Then, compare lifetime stats between FB and
To put it bluntly, a 50% loss of clicks between FB and
Also, mobile or desktop? What ad type? Are your ad URLs Voluum campaign URLs?
It's actually down to 40% now, all mobile newsfeed. I've got 10,143 website clicks displayed on my FB report and 6,020 visits showing on
Not sure what you mean in the last question...everything is hosted on AWS and linked directly to that VPS. Also fwiw, I have other campaigns (on different ad accounts) being tracked in
So, I presume your ads are direct linking to your
Are the ads being run in a different country to what is generally being run on your other accounts?
Targeting a different phone type/OS/connection type?
Maybe try adding your own simple counter before
Ahh sorry, got it. No - the ads are linking to my safe page with a cloaking script implemented below the head. As I said, this is only cloaking 5% of the clicks.
As for the other accounts, yes, the country is different. No OS targeting initially, although I did split test iOS vs android to see if it made a difference and it didn't.
Well, we can pretty safely assume that the large click loss is not at the fault of
It will be your server and/or your 'safe page' implementation.
I'm not sure what your current set up is, but if you are trying to implement some sort of cloaking and are using javascript + working with mobile traffic + don't have a reliable server that has a reasonably low latency to your users, you're going to enjoy sizable click loss.
Why are you cloaking in the first place and are you just using your own implementation?
Is your safe page hosted on your own server or a CDN? If the former, where is it?
How exactly does the cloaking script work? Is it on-page only - or is it loading a local and/or external source?
Weird!
There will be an underlying cause, but you may never be able to find it.
Perhaps make an entirely new ad in the suspect account as well to see if it solves the issue.
I highly doubt it will be anything account-related - because this would suggest Facebook is charging you more than was delivered for that account in particular, which would be malicious and be them breaking their agreement.... quid pro quo perhaps?
Have you discussed this all with the cloaker dev. Since you are beta testing his setup maybe he will help you trouble shoot your issues. What DNS service are you using?
Using namecheap.com. I spoke with dev, he thought it might be repeat clickers not registering with
As Janglib said, implement a counter at each step to see where they are dropping off.
In certain geos and markets on FB, repeat clicker rate can be as high as 50% within 24 hours and 70% within 7 days. Trackers like 202 will by default show "unique" clicks for the day.
FB->
counter ->
cloaker file or page with included cloaker file ->
counter ->
landing page (here is where it counts into
I am sure
I think
Considering Voluum have a data center in Sydney, I highly doubt this is the case.
In any case more info is needed as others have suggested.
Log click counts with a PHP script. Check if you're using SSL anywhere (this WILL have a sizeable impact on performance, especially on mobile traffic!).
Do you mean on what SSL is or why it would have an impact?
If you're dealing with quite complex interacting parts e.g. cloaker +
Check the various URLs and page code you are using for https links or relative protocol links (where it's just //blahblah.com) in the page code, which will load by https if the page is loaded by https.
Why will https have an impact? Because it takes several round trips between user and server to negotiate an SSL connection. If you have a 100 ms latency from user to server, this can lead to nearly 1/2 a second being added before you even load any page content.
yeah, I understand what SSL is, just didn't get why it would have such a big effect. regardless, i'm not using SSL so i'm not even sure why I asked lol. but yet again, you are the man Zeno, thanks.
So it looks like the click loss is pre cloaker based on my test with counters on each page. Luckily today it is back down to 25-30%...is this pretty normal compared to what everyone else is seeing for mobile?
I know this has been asked already but in FB reporting are you checking Clicks to website or Unique clicks to website.
Good news! Solved. HUGE thank you to "Ads Cloaker" - if you haven't checked out his cloaker, I highly recommend it HERE.
I figured I would give a break down of the issue/solution in order to help others who might experience similar problems in the future. This ended up being a time-zone issue in combination with Facebook somehow reporting more "website clicks" than "clicks."
For starters, I found out that the cloaker was reporting in EST, whereas FB was in PST. I looked at yesterday's Imp Logs to see see how many clicks came in between 12am-3am on the cloaker then deducted this from the cloaker's click total for today (as FB wouldn't have counted these). I then looked for how many clicks came in between 12am-3am today and added this to the total. Now I knew exactly how many clicks were recorded by the cloaker in PST for yesterday, and compared it to what FB reported.
Unfortunately, there was still a massive discrepancy between this and fb's "website clicks"...until we noticed that fb had somehow reported 1.3x the # of "website clicks" vs total "clicks". Considering "clicks" obviously takes into account website clicks, this makes 0 sense...but thankfully, we are only charged on clicks. So, after reconciling this data, it looks like I was only losing about 20% of my clicks instead of the reported 40-50%. Hopefully this helps others who like me, considered running head first into a brick wall after hours of trying to troubleshoot this issue
.