|
|
This is a tip specific for Coremetrics. Frequently you want to understand where traffic to a specific page came from. You see a spike in page views and want to understand it, you suspect a blog post may be sending traffic, etc. There’s no default report in the Coremetrics Analytics interface that shows you this, so here’s a step by step walkthrough to find the data using Coremetrics Explore.
Coremetrics Solution:
Using Coremetrics, one option is to create a report segment that has the criteria of Entry Page is the Page ID of the page you want to investigate. Then you can apply this information to the referring sites report located under Marketing. This will allow you to see the referring sites for that page ID. However, this option will only show high-level referring sites (e.g. pinterest.com, rather than pinterest.com/pin/12345).
To get specific referring URL’s, you must build the report in Explore:
Here are the steps needed to create this report.
1. Go to Explore, then click Reports –> Actions –> Build New Report.
2. Choose Flat List Report –> then click Build
 3. In Columns & Metrics data, choose Display Column as Marketing –> Marketing Channel and drag and drop Referring URL into the report box
4. Select up to 5 metrics
5. In Dates & Data Set, select the date range, and select “Run Against All Data” (unless you want to test it first with a Sample Data Set).
6. You don’t need to edit anything in the Filter tab. Click on the segment tab and click the New segment button in the lower left.
7. Choose a segment category and name. Under Segment Criteria, choose Criteria Type is Content and set the criteria as Entry Page(s) is … and enter the page name. Click Apply and Save Segment. [NOTE: If you don't know the page name, navigate to the page using Coremetrics Tools and note what value appears next to Page ID pi:]
8. Back in the Segment window, drag and drop the new segment from the Select Segments box to the Drag and Drop segments box.
9. Skip the Relational Zoom tab and move to Name & Distribution tab. Fill in the Report name box, assign a Report Category, and click submit. The report will now appear on the left hand side. It will be gray until it has completed – you can hit the ‘Refresh data about reports’ button in top right to check.
During a web analytics implementation (or audit), you need to check whether the data is being collected as planned. You can do that as follows:
The Basics: View Source Code
To identify whether basic code is on the page, you can often visit the site > right-click> View Source. Here I’ll use popular Q&A site Quora.com as an example:
Then, hit Ctrl-F to search for “_gaq” (no quote marks). This should bring up something like this:
We’re now looking at Quora’s Google Analytics source code. Here’s where you can visually check that the code is up to date, the account number is right, the vars are being named right, etc. A quick review shows that Quora could remove the _trackPageLoadTime method that’s been deprecated. Also some of those page-level scope variables look like they should actually be session-level. This shows the power of viewing the source code — it’s really easy!
Real QA: Download a Debugger
The trouble with the above method is that sometimes the code is obscured or minified so it’s not visible on the page. Also, even if the source code looks correct, there could be some issue preventing anything from being sent to GA’s servers. This is why we use debugging tools to identify exactly what is being sent to GA’s servers. These are some recommended tools:
Using these tools, you can verify that the code is actually firing and sending the right information.
Example using Omnibug Debugger
This is a screenshot of what quora.com looks like in the Omnibug debugger, so you can match it back to the original source code we viewed above.
For a full list of what these parameters correspond to, you can check GA’s reference document at https://developers.google.com/analytics/resources/concepts/gaConceptsTrackingOverview. However, I’ll focus on a few of the most useful ones here:
1) utme. This is the parameter that shows what is being sent as a custom var or event. If it is prefaced with an 8 (as in this case) it reflects custom vars, while if it’s prefaced with a 5 it reflects events. For custom vars, all the var names will be in the first array (the first set of parentheses), while all the var values will be in the second array (second set of parentheses). I put those arrows in to show more explicitly how they all match up.
2) utmp. This shows the page name that is being sent to GA. Useful if you are debugging virtual page names.
3) utmac. This is the account ID. Make sure you’re sending to the right place!
4) utmcc. This holds the cookie values. While there is a lot of interesting data in there, the most frequently used is the campaign information. This is where you can check, say, that you’ve tagged your emails properly.
Ecommerce
If you have an ecommerce site, the process is the same, but note that you will have to buy a product and go all the way to the receipt page. If you are in a QA or staging environment, this shouldn’t be an issue, otherwise get used to canceling quickly :D
Conclusion
For QA’ing to be effective, you need to check EVERYTHING. It is important to be extremely thorough — check every event, every custom variable, every page template. You don’t want to find out later that data is missing or broken, because there is no way to go back and collect it again. Hopefully this post helps get you started with the mechanics of how to QA and debug your web analytics implementation.
During a web analytics implementation, or while tracking down the source of tracking errors, it’s important to check what’s being sent to the analytics servers. Coremetrics provides 3 ways to debug or QA an implementation:
1) The Coremetrics TagBar. This is the everyday staple of QA’ing. It’s an Internet Explorer/Firefox browser plug-in that shows exactly what is being sent to the Coremetrics servers. Data shows up in the tool instantly.
To use the Coremetrics TagBar first install it from within the tool by navigating to Manage > Installations > Tools Browser Plug In.
Once it’s installed, open it up by clicking on the icon in your browser.
Open Tag Monitor to make the tags persist, which is necessary for QA’ing. These are a few of the tags you will look for.
- Page View tag: For each page being checked, check that a Page View tag exists and has the right Page ID, category ID, and other attributes.
- Link Click Tag: For Site Promotions and Real Estate tracking, you will need to check the Target HREF/URL link in the Link Click Tag. These tags will be marked by the text “cm_sp=” or “cm_re”.
Note that there will be multiple link click tags, since some are attributed to the physical link in order to populate LiveView, while others populate the site promotions or real estate reports. If the link click tag doesn’t have the query strings you’re looking for, just ignore them. It doesn’t mean the tracking is being sent twice.
Validation of cm_sp= tracking depends on appearance of the properly formatted cm_sp= value within the ‘Target HREF/URL(hr):’ parameter of the ‘Link Click’ tag. It should appear when users click on the link. Note that the site promotions parameters are tracked via this Link Click tag, not the destination URL in the link click tag or the page view tag.
- Product View tag: This is used to track product views and product information. It should show up every time there is a “buy now,” “add to cart”, or similar buy action available for a product.
Check that the correct product ID, name, and category ID are being sent, as well as any additional attributes.
2) The Implementation Test Tool (ITT). This is a testing interface that shows what has reached the Coremetrics testing servers. Point your QA site to the Coremetrics test servers and then access the data at http://itt.coremetrics.com. Data shows up within a few minutes and gets wiped out at the end of the day.
The main benefit of ITT is that you can see the cm_mmc marketing parameters that don’t show up in the tag bar. In addition it can be used just to confirm that data is actually reaching the servers, or to double check what you saw in TagBar.
To use ITT, perform all the actions on the site that you’re interested in testing. Then log into ITT and enter in your cookie ID. Entering your cookie ID isn’t necessary but it lets you filter the data for just your own browsing activities, which is what you want. You can find your cookie by setting the date range to the time period you clicked around, viewing any report, and finding your cookie in the Cookie ID field.
To see page view tags, you should select the Page View table. For site promotions and real estate tags, you should select the Parametric Links table. In the Parametric Links table, there are separate fields for Parameters 1 through 4. The Parametric_Link_Type column displays an “S” for cm_sp site promotions tracking and an “M” for cm_mmc marketing tracking.
3) Coremetrics Test Reports. Similar to ITT, this contains test data. However, rather than having a test interface, these reports look just like actual production reports, so you can view how the data will look when it goes live. Data takes the normal amount of processing time to show up — usually a day.
Between TagBar and ITT, you should almost never need to use the Coremetrics Test Reports. It is only really useful if you are testing the CDF (file that categorizes pages and products) or just prefer to see the data exactly as it will appear in the reports.
At some point during a Google Analytics implementation the question always arises: do I want an event or a custom variable for this?
I believe the reason for this is that events are very versatile in GA. They don’t just count the number of times something happened, they contain information in a structured way.
So when to use one versus the other?
First, a rundown of custom variables:
Sometimes you know extra information about your users that Google Analytics can’t pick up automatically. For example, you might know their gender, or whether they’re logged in, or have some kind of ID you use to track users across visits. In this case, it makes sense to pass the information into a custom variable, so you can use the data to create segments or tie back to a data warehouse/CRM.
Custom vars in GA have a concept of “scope”, which determines how long the variable is stored for. There are 3 levels of scope:
Scope 1 (visitor level) – this is for storing permanent info about your users, like their gender or the original channel that drove them to register. If you set this once, it will stay with your visitor until they change browsers or delete their cookies, even if the code isn’t called again.
Scope 2 (session level) – this is for tracking actions that apply to a visit, like whether they logged in or not. You have to be careful about over-writing with this since the last session-level variable called will be the one stored and reported.
Scope 3 (page level) – While this is called page level, there can be multiple page level variables on a page. A more precise definition is that it’s for tracking actions that apply only to a single tracking call, like what site sections users visited, or where they clicked. Each time the page changes, the page-level variable opens up again for re-use, so there’s usually no need to be concerned about over-writing.
Second, event tracking in a nutshell:
Typically event tracking is used for tracking on-page actions, like clicks on a page, video plays, site registrations, etc. It doesn’t need to be some kind of click action though — an event can track anything, even a page view. And this is what leads to the overlap between events and page-level custom vars.
The overlap
If you don’t need to store a variable for a session or across sessions, you could use either events or custom vars. This will apply to use cases like tracking what site sections users viewed or an action they took on the page.
My recommendation is generally to use events rather than page-level custom variables. I believe events are more flexible and powerful than custom variables for these reasons:
1) a custom variable only has 2 slots to pass in information – the “name” and the “value”. An event has 3 slots, the “category”, the “action”, and the “label”. (There is an additional 4th slot but it has to be an integer so it’s often not that helpful). So right away you get one more slot to do stuff with – very helpful if you’re trying to organize your information into a hierarchy.
2) events are tied to revenue while page-level custom variables are not! If you have an ecommerce site with several different sale pages, you could track each time a user visited these pages in a custom var. This would produce data on page views to those pages, but when you click the revenue tab, it would be ZERO. On the other hand, if you track this same data in an event instead, you can see revenue tied to views of each sale page… that’s more interesting!
3) free GA accounts are limited to 5 custom variables, while events are unlimited.
4) the visits metric makes no sense when you look at the page-level custom variable reports, as I mentioned here.
This is an example of the very bad report you get if you do a page-level custom variable to track visiting different site sections on an e-commerce site. Visits that aren’t visits and zero for all e-commerce metrics.
Summary
If you’re trying to determine whether or not to use an event or custom var you should first determine if you’re trying to track a visit or visitor-level variable. If you need to save the info to a user for an extended period of time, use the custom variable. Otherwise, push it into an event and enjoy the extra benefits.
Most people want dashboards so that they can just see their slice of the business without navigating through all the other reports. This makes sense, and for the most part Google Analytics is great at letting users slice and segment their data to do exactly that. So I was surprised the first time I discovered that that the dashboards in the new version of Google Analytics don’t have segments anymore.
While you can’t limit the data set with segments, each dashboard module lets you apply filters. Those should work. Right?
Sort of. To track how many visits I got to a blog section of the site, I viewed visits as my metric in a segment (using the criteria “Page containing /blog”) and then in a dashboard module (also using the criteria “Page containing/blog”). Finding that they didn’t match at all revealed an interesting piece of information about the page dimension:
In Google Analytics, the visit metric gets incremented each time a user hits the site for the first time. The visit is ONLY associated with the landing page. This means that if you are viewing the pages dimension with visits as a metric, these “visits” actually correspond to entrances. They aren’t visits at all!
This means you can’t make dashboards like this:
and you can’t make custom reports like this:
 do not combine pages and visits in a custom report Yikes! What do you do?
1) If you really need visits to a site section, always use advanced segments. Segments apply to the entire visit, so making a segment on a page works with the visits metric.
2) Whenever possible, choose visitors or unique pageviews rather than visits in your dashboard module.
This explains why the Content reports only show page views and unique page views, rather than visits. It also explains why any page-level custom variable is completely understated in the default report — it is really just counting up the number of entrances to that page.
|
|
