Not reported Google DV360 campaign traffic problem


Wojtek Andrzejczak
Not reported Google DV360 campaign traffic...

Thousands of Google DV360 campaign visits, which are nowhere reported, and trigger DDoS attack alarms on the server firewall. Was it a DDoS attack, or something else?

The campaign as many others

The story of our campaign happened for real. It was a typical display campaign, where a major part was set up in the Google DSP Display & Video 360. But somehow it created for the client and all involved employees a lot of stress?

From the beginning

Let’s quickly go through the campaign so you would have an idea about the scale and complexity of the setup

Campaign setup

  • 70+ landing pages
  • 280+ LineItems
  • 500+ creatives
  • Display, Video PreRolls, TrueView Insertion Orders

Tracking setup

We’ve implemented a standard Google Floodlight tracking, which counts visits on each landing page.

Enhanced attribution is enabled, and we also appended tracking parameters so we could identify our campaign traffic within the client’s analytic system.

Our client is using Adobe Analytics, which tracks all campaign traffic that lands on his website. Tracking parameters contain Google Campaign Manager IDs (like Placement ID, Site ID). This makes it easy to compare visits between the systems.

The first problems arrive

After around a week, the IT engineers of our client informed us about a massive burst of requests coming to the website. All URL’s were containing the DCLID and campaign tracking parameters. This massive volume has triggered DDoS alerts on their firewall blocking all incoming traffic.

What is DDoS?

A distributed denial-of-service (DDoS) attack is a malicious attempt to disrupt regular traffic of a targeted server by sending massive amounts of requests which could make the server unavailable to the users. You can learn more about DDoS attacks here.

Abnormal request burst

To make it even more interesting, the problem was happening every day between 12:00-14:00 CET.

Check everything step-by-step

It is easy to say but harder to do. Since this kind of problem does not happen every day, it was essential to check everything, step by step from the beginning to don’t miss anything.

Report discrepancies

Trying to compare landing page visits between Adobe Analytics and Google Floodlight reports showed massive discrepancies. Adobe reported over 85+% more visits than Floodlights, and from the tracking setup, everything was firing as we’d expect. Of course, Adobe should count more, but at this level.

URL looks normal

Since we use Enhanced attribution, to each ad click a DCLID parameter is appended, together with our tracking UTM parameters, all recorded visits look normal.

Google DV360 traffic

Tracking parameters showed that most of the problematic campaign traffic comes from DV360 ads. Other direct bookings did not show any abnormal traffic because most of our publishers use AppNexus/Xandr.

Missing Floodlight visits

Since Google Floodlights have a reporting [Conversion URL] dimension, we’re able to match the DCLID parameters with the request URL’s on the client-server.

Base on the server log from the time 12:00-14:00 range turns out that we were not able to identify 95% of all Floodlight visits: the attributed and non-attributed report, just nothing.

Data Transfer Files / Google Ads Data Hub

We could not find any anomalies in the Google Data Transfer Files or Google Ads Data Hub files. If something does not exist here, it means it did not happen, right? Right. But it happened.

Google Support

From the Google side, everything was normal. They did not notice anything unexceptional. And at this point, I believe them.

After the first email to the technical support team, the problem was taken seriously and thus given a high priority. By providing all pieces of evidence, the team was not able to find any explanation.

Google Support suspects that many QA teams were checking our ads from DV360. But I doubt that because it is not possible to open so many pages in the browser with the same tight time and repeat this operation within millisecond precision every day, at the same time.

Sadly said, for Google, our problem is now not relevant due to a low volume level and no further actions besides closing every single ticket as soon as we write to them with similar issues.

Deeper investigation

After receiving a full access log from the client-server, I was able to aggregate client IP addresses, to see if anything is interesting, which could give us some ideas.

Gotcha!

The result was quite a surprise. The most hits were coming from IP addresses that belong to Google. And to be more precise from Google proxy domains.

What does this mean? Google has many internal applications like Google Bot (it is on the list below). As an example, check 66.102.8.132 IP address and find that it belongs to Google.

client_ip requests Lookup domain
66.102.8.1323564google-proxy-66-102-8-132.google.com
66.102.6.2273304google-proxy-66-102-6-227.google.com
66.249.88.11982google-proxy-66-249-88-11.google.com
66.102.6.229488google-proxy-66-102-6-229.google.com
66.249.83.212466google-proxy-66-102-6-229.google.com
66.249.88.14425google-proxy-66-249-88-14.google.com
66.102.8.134245google-proxy-66-102-8-134.google.com
66.249.80.36228google-proxy-66-249-80-36.google.com
66.249.88.17211google-proxy-66-249-88-17.google.com
66.102.6.231142google-proxy-66-102-6-231.google.com
66.249.80.3889google-proxy-66-249-80-38.google.com
66.102.8.13666google-proxy-66-102-8-136.google.com
66.249.80.4062google-proxy-66-249-80-40.google.com
66.249.92.8438rate-limited-proxy-66-249-92-84.google.com
66.249.83.21415google-proxy-66-249-83-214.google.com
66.249.66.1494crawl-66-249-66-149.googlebot.com
66.249.92.863rate-limited-proxy-66-249-92-86.google.com
66.249.83.2162google-proxy-66-249-83-216.google.com
66.249.88.201google-proxy-66-249-88-20.google.com
66.249.92.881rate-limited-proxy-66-249-92-88.google.com

Source of the problem

It turns out that a possible DDoS attack was just some kind of Google App since we identified in our initial reports that traffic was coming mostly from Google DV360.

Our first guess was the Google DV360 audit tool, which checks if a landing page is available. Which means it had to generate a physical click with the DCLID parameter and campaign tracking parameters, and check if the landing page was available. It means that the page must have been fully loaded, and allowed analytics software to count a visit.

So what now?

The problem was addressed to Google Support directly. But unfortunately, the traffic volume we had was “not significant”. And since it involves some internal apps/humans visits via Google proxy, it is not possible to identify the problem with high accuracy.

Together with Moritz Schneider, CEO of Hoy AG, we do not stop at efforts to identify and resolve the described problem to avoid similar issues in the future.

Summary

How Google products count their traffic?

They don’t. In the same way, how Google Analytics does not count Google Bot traffic. If the source comes from a Google Proxy no traffic is collected in any Google product.

That’s why Google Marketing Platform does not count any impressions and clicks for the ads, and Floodlights don’t include any impressions.

What about Adobe Analytics?

By default, it should not collect Google Bot traffic, but I guess it does include visits coming via Google proxy servers. It means that in the case of DV360 campaigns, Adobe Analytics might record more campaign traffic than Google platform. This might be one of the reasons for many discrepancies problems.

Subscribe to receive updates about new articles.

Links

Show Comments (0)

Comments

Related Articles

Google Display & Video 360

6 steps to activate Floodlight in DV360 • TrueView for Action

6 steps to activate Floodlight in DV360 for TrueView for Action campaign.

Posted on by Wojtek Andrzejczak