Getting Yahoo PPC to add its own markers to landing page URLs

Yahoo Pay-Per-Click (PPC) does a fantastic job of automatically adding tracking parameters to landing pages for your PPC ads.

You have to turn it on in the Yahoo PPC interface. Here’s how.

2011 note:  We’re going to revise this to reflect Bing’s and Yahoo’s current state.

(Applies to: all)

Um, for newbies we probably ought to define “markers” first, as used in the title.

When we say markers, we mean special query parameters (in the landing page URL) that mark something for tracking and reporting purposes.  They’re also called

  • “tracking variables”
  • “tagging your ads” (in PPC)

These parameters have no other function than tracking.  They don’t alter the page content the way .asp parameters do.  They’re just there to say “this hit is a little different, it comes from a paid search ad” or “it comes from a particular banner campaign” or “it comes from a particular email.”

An example would be a pay-per-click landing page URL that has

  • a marker parameter that informs you that the page was reached from Yahoo’s PPC program
  • another parameter might tell you exactly what paid-for term caused the visit
  • another that relays the search term actually used by the searcher

Normally (i.e. in Google AdWords, which we’ll call “normally” today) you have to insert these parameters in the landing page URL yourself and supply that modified landing page URL to Google.  Google does have a feature for automatically attaching an encrypted parameter called “gclid” but only Google Analytics can decode it into a search term.

However, Yahoo Sponsored Search does a fantastic job of automatically adding markers to landing pages.

It’s not on by default, so here’s how to turn it on.  In the Yahoo PPC admin, go to:

Account > Account Set Up > Overture Tracking URLs

The tracking URLs check box is in the lower right quadrant of the Account Set Up page, or it was the last time we looked.

Yahoo adds these parameters:

  • ovkey=   the actual term paid for
  • ovraw=   the term that the searcher actually used
  • ovmtc=  the match type used to match the searcher’s term to your paid-for term

Consider a custom report or URL Parameter Analysis report of two dimensions:  the actual term paid for (ovkey), and the term used by the searcher (ovraw).  Look through the results and find inappropriate matches.  They’ll give you ideas for negative keywords and, voila, your reports are actually helping you save money!

Related Posts:
Actual vs paid-for search terms
Beyond WT.srch – the better way to track PPC

Reasons for “Direct Traffic” in referrer reports

Here’s our current list of reasons for an empty referrer field, a.k.a Direct Traffic, or more accurately “Referrer Unknown Traffic.”

“Direct Traffic” is a legacy label that no longer makes sense.  Once upon a time, in long-ago simpler days (approximately 2003), the absence of a referrer in log files could only mean that somebody typed your site’s name into the browser’s address window, or used a bookmark, which amounts to the same thing.

No longer.

Here’s our current list of reasons for an empty referrer field, a.k.a Direct Traffic, or more accurately “Referrer Unknown Traffic.”

Although this list will help you find ways to reduce your Direct Traffic to more realistic numbers (i.e. closer to just reporting on #1), Direct Traffic is still a mess.  Or, as Jacques Warren once said, “I, for one, never use Direct Traffic in my reports and analyses anymore. It’s full of unreliable crap.”

  1. Somebody really did type in the address, or used a bookmark to get to your page.
  2. They clicked on a link in an email.  (Not always true.  If they used some kind of web mail, the web mail server will usually be the referrer)
  3. The link was in a document, Excel workbook, or PDF
  4. The link was in Skype, GTalk, or AIM
  5. The link was in a mobile app and opened your site in a browser.  For example, clicking on a URL in a tweet viewed in a Twitter app, or a mention seen in a Facebook app.
  6. The link originates at a secure (https:) page and your page is not secure (http) (this sometimes includes web mail servers)
  7. Spiders and bots were working from a list of URLs from a previous crawl (this one mostly applies to server logs, rarely to SDC)
  8. Spiders and bots may be programmed to suppress the referrer information (this one mostly applies to server logs, rarely to SDC)
  9. The link to your site was in Javascript (this is mostly a problem with IE).  Javascript links to your site include those that open your site in a new browser window, or any kind of javascript redirect.  Many banners’ links are programmed this way.
  10. The link to your site is from within a Flash application (mostly a problem with IE) (there are a lot of ways to do this in Flash so there may be exceptions)
  11. Your landing page redirects to another page via a 302 temporaryserver-side redirect
  12. The link was on an intranet or some other web site behind a proxy or corporate gateway that was set up to strip referrers from requests
  13. The visitor has made changes to their browser that suppresses the referrer information
  14. The visitor has set one of your pages as their browser’s home page
  15. Another site has put your page content into an iFrame and coded the frame to suppress the referrer, in order to make it difficult for you to find out who is framing your content
  16. Certain A/B situations where visits directed to the B page group are redirected via 302  from the control page (A) to B too quickly for the tag to fire on A.  Check with your A/B vendor about whether this might happen with their product.

As you can see, IE is responsible for a big proportion of non-referrer visits.  If you want to get a better idea of your referrer mix, you could try a Firefox-only Referrers report, or Firefox+Safari (with Safari, you’ll get a lot of iOS mobile though).

If you want to do a little more sleuthing, go to a search engine and request a list of all the indexed pages that have links to your site (or to a particular page).  (Search for “”)  Visit those pages to see if the links have the quirks described above.


Search engine traffic that uses your domain name as the search term really should be classified as Direct Traffic, because for all practical purposes it is the same as typing the URL into the address bar.   You might want to add these to your reporting on how much of your traffic is Direct Traffic.

A lot of marketing traffic (email, sometimes banners) comes through as Direct Traffic for various reasons described above.  If you are properly marking your campaign traffic with landing page parameters (WT.mc_id for example) you can quantify this traffic and subtract it from your estimates of Direct Traffic.  Try a report that is filtered to exclude traffic with a referrer and any value of WT.mc_id.


How to tell WebTrends about a bug or a change you’d like

This tip isn’t for getting help or support.  It’s for something more important — giving feedback to WebTrends that will improve the whole WebTrends universe.  We hope.

From the Admin screen:

     Customer Center > Contact Us > Submit Product Feedback

If you’re reporting a bug, give enough detail so they can reproduce it.  Include what DID happen as well as what SHOULD happen.  A good format for reproduceability is “Do this, then this, then this.  It shows such-and-such.  It should show such-and-such.”

If you’re requesting a change or feature, explain why you think it’s important.  Given an example of a “use case” if you can. 

Trust us — the Insiders in Portland really pay attention to what flows into WebTrends from this screen.  Submissions get triaged as well as generally circulated among smart people.  You’ll rarely hear back, but have some faith that your input is being seen.



The WebTrends *.wlp file — knowing enough to be dangerous

(Applies to:  software)

It’s early in the history of the WebTrends Outsider and we may as well get in big trouble right away.

This topic is about the *.wlp files.  You need to know that they exist and you might actually find them interesting.  And once in a while you will need to alter one — for example when dealing with the issue of the Pages report showing both www and non-www versions of your domain name, resulting in double listings for some pages.  The fix for that problem involves adding a line to a .wlp file.

Nobody seems to know what “wlp” stands for.   You just need to know that it’s the mother configuration file for a profile, and every profile has one.

You will need:

  • A text editor (Notepad is unsafe because it blocks access for the files it has open.  Invest in TextPad.)
  • Access to the WebTrends program directory on the WebTrends server (i.e. have the necessary privileges and permissions to browse around in there and open files)
  • The semi-secret GUID of the profile you are interested in (this is the 11-character string that appears in greyed-out font in the Profile File Name field of the General tab when you edit a profile.  Or, when you are looking at reports, it is in the address bar as the *.wlp filename) (GUID stands for “Globally Unique Identifier.”  The GUID will stay constant no matter how often you change a profile’s title.  This is a good thing.)

Ready?  It’s best to look at *.wlp files when WebTrends isn’t actually analyzing or displaying anything. 

Using Windows Explorer (or any file browser) find your WebTrends program directory.  Go here:

     … Program Files / WebTrends / storage / config / wtm_wtx / datfiles / profiles

In the /Profiles folder you’ll see *.wlp and *.bak files, for all your current GUIDS and maybe some old ones too.

Open the *.wlp file that has the same name as your favorite profile’s GUID.  (This would be a good time to tell Windows that you want all *.wlp files to be opened with TextPad.) 

Now, just read through it.  Did you find it interesting, even exciting?  Then you have the makings of a WT hacker.  Was it scary?  It’s just as well.  You really don’t want to change anything in these without somebody telling you exactly what to do.

That’s it.  End of tip.  Just thought you should know.



Managing www’s in the Pages report

(Applies to:  software)

If this is happening then your underlying problem is that your site server is set up wrong.  Talk to somebody in charge of the servers and ask about making all requests for “” redirect (301 type) to “”  If they tell you they don’t know how to do it, question their right to hold their current position.  They’ve already got one foot over the line by letting this happen in the first place.

Meanwhile, here is a more constructive workaround if you use software.  You have to make a change in a config file.  If you re-analyze data, the old data will be corrected.  If you don’t re-analyze old data, your new data will be okay, but any page reports referring to old data will show those problem domain names.  It’s best to re-analyze.  Re-analysis is one of the perks of having the software version of WebTrends.

Here’s the trick.  Add the following line to the [profile] section of the profile’s .wlp file:

       overridemultihome = 1

This line forces WebTrends to ignore the “host domain” field of logs.  WebTrends will instead display, as the domain in pages reports, whatever you entered as the Web Site URL field in the Home tab of the profile’s setup.

You have to be a little careful.  This is all or nothing.  All domain names in the logs will be overridden.  If your logs have other important domains in them, think about other solutions such as editing the logs before analyzing them.

However, domain name filters (applied at the profile level) will still work!  The multi-home domain filter takes effect before the domain name suppression happens.

What?  You don’t know about .wlp files?   See the .wlp file topic.