With the rapid adoption of Tag Management Solutions (TMS), the ability to deploy marketing conversion pixels has never been easier. However, with that ease comes the potential danger of pushing marketing pixels to your site without regard to process or governance.
This undisciplined approach to pixel management often leads to sites becoming bloated with pixels, many of which are for campaigns that ended months, if not years, ago. A marketing pixel wasteland, if you will.
This collection of pixels in disrepair is not only an eyesore, it may be having very real consequences on the performance of your website.
According to a study conducted by KISSmetrics, 40% of site visitors abandon a website that takes more than 3 seconds to load.
A process for managing marketing pixels through your TMS doesn’t have to be complicated, in fact, the process you design should not take away from the increased speed-to-market that using a TMS offers. Note that a small amount of structure will go a long way to keeping you from creating a pixel wasteland.
Pixel Management Process
Consider the following workflow that we have deployed for many of our clients:
Pixel Request
As organizations tend to work with many 3rd party marketing agencies and multiple ad networks, how pixels are requested and communicated differ widely from agency to agency. A lack of standardization around the pixel request process often leads to inefficiencies, even when leveraging a TMS, in deploying marketing pixels.
We make use of a simple request form that is sent to all outside agencies that request pixels be deployed to the site. This not only allows for us to collect critical information about the pixel but also provides a standard way to communicate the request to the resource that is responsible for deploying marketing pixels.
The request form captures key information such as:
- Vendor that is requesting the pixel
- Marketing campaign the pixel is supporting
- Targeting logic e.g. what pages will the pixel be deployed to
- Start and end dates of the campaign
- What META data, if any, the pixel is required to capture
- Any special instructions for deploying the pixel
- And finally, the pixel code itself
Request Tracking
Once a pixel request form has been received, existing internal processing for tracking development requests should be followed. Don’t use your TMS as an excuse to skirt around proven development processes. Many of our clients leverage solutions such as JIRA to manage these types of requests.
Regardless if you use a robust solution like JIRA or you manually track your pixel requests using a spreadsheet, it’s critical that each request gets logged and a tracking number assigned — when this workflow hasn’t been followed, I’ve literally spend hours backtracking through email to find details about a pixel request.
Again, this doesn’t need to be complicated, assign a unique tracking number and assign a resource to deploy the pixel in your TMS.
TMS Architecture
Once the pixel request has been logged into your tracking system of choice, the TMS architect can read through the details of the request and begin thinking about the ideal way to deploy the pixel.
This is a critical step that is often over looked, Again, it’s so super easy to deploy pixels in a TMS that it’s tempting to just pop open a rule, add the pixel, and get on with your day. While you may be tempted, don’t go down this path. Take the time to properly design an architecture that will allow for maximum scaleability and efficiency.
Pixel Creation
Once you have decided on an appropriate architecture, now comes the time to code the pixel into your TMS. As you code the pixel, consider the following best practices that we have developed:
Pixel Name Taxonomy
Create a standard naming convention that you follow for all pixels. Trust me, this will save you many hours of lost work and frustration later on. We recommend the following:
Format: Vendor – Campaign Name – Location – Tracking Number
Example: Facebook – Spring 2016 Retargeting – Order Confirmation – #38393
In-Pixel Documentation
Take a few minutes to document some key information about the pixel, inside the pixel code itself.
var killDate = new Date("MM/DD/YYYY"); //INPUT CAMPAIGN END DATE
var vendorName = "" //INPUT NAME OF MARKETING VENDOR
var requestNum = "" //INPUT TRACKING REQUEST NUMBER
var tagName = "" //INPUT NAME OF TAG/PIXEL
Standard Pixel Wrapper
We make use of a standard pixel wrapper that provides two primary benefits. First, it allows us to programmatically stop individual pixels from firing based on the defined campaign end date (see the previous step, In-Pixel Documentation) and second, it allows us to output some critical information to the console that can be used to monitor, debug, and analyze pixels as they fire.
The following is the wrapper that we use for those clients leveraging Adobe DTM. Feel free to take this code and modify it to best suit your specific needs.
QA & Launch
Finally, please follow any existing QA, approval, and deploy process that your organization has in place. While this can often outside of an official production release cycle, it is critical that any code deployed through your TMS is properly tested prior to deploying to your production environment. It just makes good business sense.
Having deployed this workflow with many of our clients, I can attest that it does not in any way take away from the advantages of using a TMS, in fact I would argue that deploying a process like the one described above will actually end up saving you time and money.
[author] Jason Thompson [author_image timthumb=’on’]http://i2.wp.com/33sticks.com/wp-content/uploads/2015/02/jason_250x250.jpg?zoom=2&w=1080[/author_image] [author_info]Jason is the co-founder of 33 Sticks. In addition to being an amateur chef and bass player, he can also eat large amounts of sushi. As an analytics and optimization expert, he brings over 12 years of experience, going back to being part of the original team at Omniture. [/author_info] [/author]