How to Prevent Tracking Codes from Crashing Your eCommerce Site
By Robert Mech, Applications Coordinator
You just launched the largest marketing campaign in your website’s history. You’ve leveraged social media, and your website got a spot on the nightly news. Your boss is watching the sales flow in, and then…….
The crash. Your site is down and every second is revenue lost. Panic sets in as your Support Team works to bring your site back up. So what happened?
Server Side Caching and Speed
The ability to quickly, efficiently and effectively serve up your company’s eCommerce pages is a function of your hosting environment. In this case, the simple explanation is that the servers were stretched to capacity trying to handle all of the incoming page requests. As a result, they stopped handling page requests and your site shut down.
One reason the servers were so stressed was that they couldn’t build a cache where information is rendered and stored as static content. A cache speedily serves up frequently requested pages. This frees up the application and database to create pages involving dynamic data (i.e. data that changes) such as shopping cart data and account data.
Email Marketing and Tracking Codes
Let’s take a look at what happens when marketing sends out a large email campaign promoting a weekly sale. A link in the email will lead to a dedicated landing page for the campaign.
You develop your content and products for the landing page, and it has a URL of http://www.awesomesite.com/week-1-sales.html. When the first visitor clicks on the link to this page in the email, the request goes to the database to find the information needed to create the page. It takes two seconds to return the page to the user.
In general, a landing page is considered a static page. After the first user request, a copy labelled for /week-1-sales.html is placed in the cache for the next time a visitor requests the URL. Subsequent visitors who request the landing page will have a much faster experience because the page is served from the cache instead of being built from scratch. Speed increases roughly 75%. This is an example of how cache in Magento, Demandware, Drupal, and Varnish works.
However, the marketing campaign is designed to do more than just drive sales. Marketing wants to learn who opened the email, clicked on the link, and made a purchase. Each email sent receives a unique identifier or tracking code for that customer so this information can be gathered.
The URL will now look like http://www.awesomesite.com/week-1-sales.html?cID=HDY7Semail@example.com&grp=3. The text in red represents the tracking code. It contains the campaign ID (cID), the users email, and what group (grp) in which it was sent.
The URL doesn’t go directly to www.awesomesite.com. First it goes to the email provider to track that a customer opened it. From there the customer is automatically redirected to the actual landing page. This process is so seamless that your customers won’t even notice it.
You can check for the tracking code the next time you get a promotional email. Hover over a link in the email and you’ll see something like http://cc.mailprovider.com/clickThrough?cID=HDY7Sfirstname.lastname@example.org. Here’s an example:
How a Tracking Code Affects the Cache
The cached page is built from the original URL – http://www.awesomesite.com/week-1-sales.html. However, the tracking code for the first visitor changes the address to http://www.awesomesite.com/week-1-sales.html?cID=HDY7Semail@example.com&grp=3.
The web application and the cache have no way to know if those parameters will result in different content. If we send the email campaign to five customers, each visitor has to wait for a new page to be built (two seconds per page). The cache would contain pages built for each user request. For example:
http://www.awesomesite.com/week-1-sales.html (the original page)
Now you can understand why the server is so stressed if a 40,000 messages go are sent with tracking codes. Imagine everyone clicks the email link at the same time. The cache can’t be used. Instead, the server has to build 40,000 pages where the only thing that differs is the tracking code, most certainly resulting in a server crash. If those same visitors all went to the original landing page http://www.awesomesite.com/week-1-sales.html, the total processing time would be 4.5 seconds (two seconds to build the page, then .5 seconds per visitor to retrieve the cached page).
Email campaigns aren’t the only cause of cache defeating URLs. Referrals can be another source. Referrals come from pay-per-click services like Google and Yahoo, or you may run an affiliate network that also send referrals. If your site participates in referrals, then you will often see a refID parameter in your URLs. One example might be http://www.awesomesite.com/week-1-sales.html?refID=298374.
Managing Cache Defeating URLs
Now that you have a basic understanding of the role that caching plays in site speed and performance, we can take a look at some of the ways your Support team can mitigate the issue.
- Traffic Analysis. A Systems Administrator can conduct an analysis of the web logs for a specific URL and tell you what parameters they see coming across for a particular address. This audit will take a little bit of time, but is a best practice for keeping your website running smoothly.
- Traffic Throttling. Slowing service to regulate network traffic and minimize bandwidth congestion is a simple and effective way to prevent a server crash. It won’t prevent unnecessary cache build-up, but spreading a 40,000 user email blast over two or three hours will keep your site running. However, this is not always a viable option when you have a time sensitive promotion on your site.
- Magento Page Cache Filter. For Magento users, LYONSCG has created a Page Cache Filter application. This plugin, which has been tested with Enterprise 1.8 through Enterprise 1.14.x, enables Support to use the platform’s admin panel to signal what URLs to ignore when looking at the cache. Let’s take a look at how it works.
- Once Support installs the module, they navigate to System->Full Page Cache Filter to define the filters. Using our previous examples, the URL we are receiving is: http://www.awesomesite.com/week-1-sales.html?cID=HDY7Sfirstname.lastname@example.org&grp=3
- The elements in red are the ones we need to filter out, and will be added in the admin panel through the custom interface.
- The Page Cache Filter does not remove the parameters since there is no way to know if a parameter will be used by some other module. Instead, the Page Cache Filter works by excluding the specified parameters from the full page cache storage. The result is that the tracking code URLs now look identical to the cached page. Because the cache is used, speed is improved and the visitor has a good experience.
- The Page Cache Filter will exempt any URL parameter you select so that it can be used in many scenarios. Here are just a few of the common parameters added.
- Listrak, an email personalization provider – utm_source, utm_medium, utm_term, utm_campaign parameters
- Google’s unique gclid parameter
- Custom trackers like email=
- Usablenet, a mobile marketing service provider – stop_mobi parameter
Marketing campaigns are great for driving business to your eCommerce site, but too much traffic in a short time can interfere with speed and performance. The tracking codes such campaigns use to provide valuable customer data prevent the efficient use of caching.
Work closely with your Hosting and Support team in advance to prevent issues with cache defeating URLs. At the same time, you can benefit from an assessment of other potential situations that could impact site speed and performance.
If you have any questions about how a Hosting and Support Team can optimize your site for speed and user experience, feel free to contact LYONSCG.
Want to read more about site speed, hosting and support, and other related topics? Check out these LYONSCG articles:
eCommerce Site Speed: How to Measure
Selecting eCommerce Web Hosting and Support
Web Hosting and Handling Traffic Surges
Robert Mech is an Application Coordinator at Lyons Consulting Group. He works closely with the Application Hosting team to engineer and manage large scale Magento and eCommerce implementations. When he is not working hard for LYONSCG, Robert spends his free time enjoying science fiction novels and spending time with his wife and four children.