Pixel problems: Troubleshooting your paid media tracking implementation

You have just launched what might be the greatest campaign of your life. You’ve nailed the research, dialed in your keywords and you have a grand vision for the success you’ll inevitably encounter. People will be chanting your name in the streets and writing articles about your innovative approach, and how you can rightfully include “gamechanger” in your LinkedIn bio. Like a kid on Christmas morning, you can’t wait to see what you’re going to get so you check in on your campaign after a few hours… no conversions. But that’s OK, these things take time, right? You look the following day again – still no conversions – and doubt starts to creep in.

What could be wrong? Your campaign is driving lots of engagement and your analyst is telling you that sales appear to be up, but it’s hard to say what’s driving them. You realize that it wasn’t your campaign build after all but instead, it’s your tracking. Your feedback loop is broken and you don’t know why. Queue the long-chain of emails with your developers trying to explain the ins and out of pixels to a team that is already overburdened with requests and doesn’t understand why your need is so immediate. Combined with several frantic searches on the topic, you’ve now landed on this article in the hope that this will solve your problem – welcome.

This article focuses on troubleshooting tracking for GoogleAds and BingAds, although the solutions contained will also extend over to other pixels (e.g., Facebook Events) that would fire based on the same user actions.

Tag management

It’s 2019. If you’re not using a tag management solution by now, what are you waiting for? I highly recommend using a solution like Google Tag Manager (free) or Tealium (paid). For this article, we will assume you’re using one. Hardcoding tags onto your site gets very messy, limits your flexibility to trigger (or to mitigate) tags and in general requires significant development support for even the smallest change.

Before you troubleshoot your configuration within your tag management solution, perform a simple crawl on your website to ensure that your tag container appears on every page of your website. Using a tool like Screaming Frog will allow you to see if some pages (or sometimes entire subdomains) are missing tracking and potentially save you a lot of time before you head down the rabbit hole.

What actions trigger your conversions?

As we think about troubleshooting, the first thing we need to understand is how you’ve configured triggers to fire the conversions created within your accounts. Are you using a pageview (most common), an event? Or something else entirely?

GTM makes it very easy to use both the GoogleAds and BingAds templates. For Google, you need to add in your conversion ID and label associated with the appropriate trigger (this could be a pageview or an event) and include any exceptions that may be causing false positives.

In this example, there is a validation event that fires when a specific form is completed and the website displays a success message.

Often I see marketers place click-listeners on a form submission button, rather than waiting for validation that the form submission was successful. It’s highly likely this will result in over tracking as it will also include all incorrect form submissions (where a required field is missing) along with those that go through inflating your data.

You’ll notice in the example above that we have also included an exclusion for this pixel firing within the dev and staging environments. This is to prevent any rogue individuals internally inflating your data when performing test transactions and leading you to believe that some obscure long-tail non-brand keyword is more efficient than your brand terms.

Similarly, here’s an example of the ideal configuration for Google Ads transaction tracking. Note the inclusion of the OrderID as a variable to support deduplication within Google Ads (if you accidentally do fire it multiple times on the same user conversion event) as well as the dynamic revenue field.

For any dynamic values you’re pushing into this tag, these need to be picked up from the dataLayer in advance. All around Analytics Superhero, Simo Ahava has a fantastic article on persisting dataLayer variables across pages when they may not appear on the thank you page for example.

Quick Tip: It may sound almost too simple, but be sure to double, and triple check, your conversion ID and label data to ensure that it matches across platforms. It’s very easy to overlook this and will drive you up the wall trying to solve the problem when everything appears to fire correctly.

Now we are ready to check the validity of the firing trigger. It’s important that we troubleshoot this in two ways: Does it fire when it should be based on the rule we have set up? Does it fire based on any other actions when it shouldn’t?

To do this, we’ll want to initiate preview mode within Google Tag Manager and initiate a test conversion. You do not need to go through a paid search ad to do this. Rather, the conversion pixels should fire for ALL conversions and the platforms (Google and Bing) will match this back if they have previously tracked a user interacting with one of your ads.

In addition to using preview mode, I recommend creating a recording using Google Tag Assistant. This extension will allow you to create a log of all events that fire (for Google platforms) and the data that is passing along with them.

Once you’ve initiated both of these tools, perform your conversion action and you should see something like this:

Using preview mode in Google Tag Manager will allow you to see what tags will be triggered without needing to publish them first.

Now find the tag you wanted to fire. All tags will be present, but they will be split into “Tags that Fired” and “Tags That Did Not Fire.” If your tag fired – great, check that the data being passed along is correct. If it is, then there shouldn’t be an issue. If your tag didn’t fire, then you may have a problem with your trigger. Start by reviewing what did fire on the page and the associated triggers. Next, click into the tag you wanted to fire and see what rule wasn’t met. Using this to communicate with your development team will go a long way to hone in on the issue to make technical changes.

Of course, there are so many different reasons why you may not be tracking conversions accurately. I sat down with my coworker, Wpromote’s Director of Development Mike Ulrich, to come up with a short list of quick hits for problems you may run into and the most likely solutions based on hundreds of implementations handled by our company.

Problem: No conversions are being recorded

Possible Reasons:

• The trigger is being blocked or has not been set up correctly. Review within preview mode to see if any of the rules mismatched (and thus stopped it from firing).
• The trigger isn’t firing due to a tag sequencing issue. A delay can cause an issue when content loads and the user closes the page before your tag firing.
• The tracking IDs are incorrect and the trigger works causing data to pass into another account.
• The conversion is firing but fires before the conversion data is available in the dataLayer.

Problem: No dynamic data (revenue) is being captured

Possible Reasons:

• The conversion pixel is using the wrong dataLayer variables (i.e., there is a mismatch).
• No dataLayer variable has been created to push dynamic data.
• The confirmation page has been changed causing the data passing into your dataLayer to break.
• The data object used to push conversion data into the dataLayer is broken or has been removed.

*Note: Your dataLayer is the most powerful aspect of any analytics implementation. It’s crucial that both you and your development team are aligned on what kind of data you need to be able to pull from here and how it will populate.

Problem: Too many conversions are being recorded

Possible Reasons:

• TransactionID is not unique and is unable to be deduplicated if the conversion is triggered multiple times. Transaction deduplication occurs on the platform side (once the data has passed to Google Ads) and as such requires the transaction ID persists as not to double count.
• The confirmation pages transaction data isn’t session based, causing duplication when you reload the page in a different session.
  • Note: This is a particular issue we have observed with Shopify and requires a custom script be added. You can read more about the required solution on Shopify Help Center.
• The same conversion pixel exists in both a hardcoded state on the site and within your tag management platform. (Platform should deduplicate if transaction IDs match.)
• There is no form validation in your trigger to limit conversions to only full form submits.
• The is no rule set to limit your conversion pixels to only fire once per page load.

Given it’s highly likely you’ve stumbled upon this article because you’re dealing with some pixel tracking challenges, I wish you the best of luck and a speedy resolution. Just remember to take a calculated, iterative approach to troubleshoot to avoid chasing your own tail. Even the best developers can end up in a troubleshooting feedback loop at times of heightened stress!

---

Opinions expressed in this article are those of the guest author and not necessarily Search Engine Land. Staff authors are listed here.

---