Mailbag time! It’s been quite a while. I’ve been getting some great questions from really talented analysts and marketers. Seriously, everyone is getting smarter. I’m barely keeping up. Here are just a few of these questions, collected from e-mail, Twitter, and in-person conversations. . . and here’s hoping I don’t go another 17 months between mailbags, eh? Please send me your questions via the comment form on this blog, or tweet at me (@benjamingaines).

Q: Let’s say I am looking at a Campaigns report showing Click-throughs (or Instances in an eVar report) and the new Entries metric. For different line items in the report, sometimes Click-throughs is higher than Entries and sometimes the opposite is true. What is going on?

BG: There are a few reasons why Click-throughs might be higher than Entries, and vice versa. First, let’s make sure we’re clear on what these two metrics mean in a Campaigns report. Click-throughs represents the number of times that a tracking code for the given campaign was passed into SiteCatalyst. When a user clicks on an affiliate link that has been tagged with one of these tracking codes, he is taken to your landing page and the tracking code is captured in a JavaScript variable (s.campaign). That data is sent into SiteCatalyst and a click-through is recorded. Entries represents the number of times that a user’s visit began with a page where a tracking code for the given campaign existed. An entry can only happen once per visit.

Now, why would Click-throughs be higher than Entries for a campaign?

  • Users might record multiple Click-throughs per visit, even for a single campaign. This can happen if the user goes back or forward in his/her browser and hits the landing page multiple times.
  • A click-through might occur on a page other than the first page of the visit. As an example, I might go to your home page by typing in the URL. Then I remember that I saw an ad on another site for 20% off of the product I want to buy, so I find that site in my browser history and go there. Once I have found the link to your site, I click on it, returning me to your site and counting a campaign click-through. But my visit started moments ago on your home page. Thus, this would be a click-through but not an entry for the campaign.
  • In rare cases, you may have an implementation problem where you are sending multiple beacons on the landing page, and the one where the tracking code is set is not first in order, thus inadvertently causing the problem described in the previous bullet point.

Why would Entries be higher than Click-throughs for a campaign?

  • Remember that a campaign can “persist,” meaning that SiteCatalyst remembers its name or value for each user who comes to your site via one. It’s possible for you to set the campaign variable to persist for a length period of time (e.g., a month) or even indefinitely. This allows you to do some interesting reporting to answer questions such as, “How often to users who first visited via Campaign X return to my site over the next six months?” It is important to note, though, that metrics like Entries will be associated to a campaign that has persisted from a previous visit. So if a user returns to your site for a subsequent visit and has a campaign that has persisted from a previous visit, that campaign will receive credit for an entry, even if there was not a campaign tracking code set in the JavaScript on the first page of that subsequent visit. This would count potentially multiple entries over the course of several user visits, but perhaps only a single click-through.

Segmentation can also create some interesting relationships between metrics. For example, let’s say I have applied a segment to exclude all U.S. visits. But I have some visitors who use laptops or mobile devices, and travel between the U.S. and other countries. Let’s imagine that one such visitor clicked through a campaign while he was in the U.S., and then made a number of subsequent visits while he was outside of the U.S. Only those subsequent visits would be included in my segment, and all data from my first visit (where the click-through occurred) would be excluded. If my tracking code persists for multiple visits, I could see 0 click-throughs and, say, 5 entries in this report.

Q: Why can I only exclude five IP addresses using the Admin Console?

BG: This came up on Twitter a while back and I wanted to clarify for everyone: you can now exclude up to 50 IP addresses or ranges in the Admin Console. Many of you who have been considering a VISTA rule to exclude a bunch of IP addresses can probably do everything you need to do within the UI now. To get started, go to Admin > Exclude by IP.

exclude IPs in SiteCatalyst

Q: Can you please tell me what “Loc. #” is and what is the difference between Loc. # 0 and 151 or 169?

BG: Location number (Loc. #) is how ClickMap attempts to record exactly where on the page a link occurred. This “metric” appears in the ClickMap report within SiteCatalyst and nowhere else. You can read more about it in my old ClickMap post that still mostly applies. Essentially, some browsers allow ClickMap to obtain a numbered list of everything on the page. When a user clicks a link, ClickMap can determine that the link was element 151 or 169, which helps it assign that click to the link and then build an overlay when you use the ClickMap browser plug-in.

If a user’s browser does not provide this information, ClickMap can still determine where the click occurred, but it does not use the location number. That’s why you sometimes see Loc. # equal to zero.

Q: How can I manage my segments in SiteCatalyst 15?

BG: This one is not a real question from a user, but since I didn’t blog about it when it was released, I figured I should mention that last month we added the ability to edit and delete segments directly in the segmentation drop-down menu in SiteCatalyst 15. Now, when you expand the menu, you will see three icons next to your segments that were created in SiteCatalyst or Data Warehouse:

delete a segment in SiteCatalyst 15

The little blue “i” gives you a window that shows the segment definition, so you can be sure that it’s the one you want to apply. The pencil allows you to edit the segment definition (so you no longer have to create new segments to iterate on existing ones!). The red “x,” as I’m sure you guessed, allows you to delete a segment. BONUS FUN FACT: If you delete a segment that is in use by a Data Warehouse report, the Data Warehouse report will not be impacted. The segment will be applied as expected. So you don’t need to worry about breaking your DW reports by deleting a segment.

This doesn’t apply to all segments in the drop-down menu; the built-in segments, those that were created by another user, or those that were created in Discover, cannot be deleted or edited; you can still view their definitions, but you cannot change them.