If you are experiencing duplicate article or landing page entries in your Chartbeat data, either in your Real-Time or Historical dashboard Top Pages lists, this is almost always caused by an issue in the implementation of your Chartbeat tracking code. We suggest reviewing the steps below with the team responsible for implementing Chartbeat tracking at your organization to understand the underlying issue and correct it in your code configuration.
- Understanding page identifiers in Chartbeat
- Supported path variables for each platform (web, AMP, FBIA, app)
- Canonical links versus custom page paths
- Identifying and correcting duplicate page path values in your Chartbeat code
Understanding page identifiers in Chartbeat
Most web analytics tools rely on a piece of page metadata sent from each page of your site as the unique page identifier to enable traffic data aggregation at the page level. In Chartbeat, this metadata element is the page path which we collect from each page of your site where our tracking code is configured. Most often, the page path consists of the domain name and path portion of your website URLs. For example, the text in red in the following URL would be the expected path we receive from a visitor who accesses this page:
https://www.yourdomain.com/index.html?source=email
For each of the platforms we integrate with, we provide implementation methods to send our servers page paths that are consistent across all of the device types and platforms where visitors access your content. Here is a table with each of our unique integrations and the configurable page path variables supported within each:
Supported path variables for each platform (web, AMP, FBIA, app)
| Standard Web |
useCanonical: Our default recommended setting for collecting page paths from your web properties. When set to 'true', our tracking script will collect the path portion of your site's URLs from the rel=canonical element (the "canonical link") in your site's header. Your webpage templates must include this HTML element for our tracking script to collect page path data with this setting. More information on canonical links below. useCanonicalDomain: Also included in our recommended web tracking configuration. When set to 'true', this variable ensures that we collect the domain name portion of the page path from the canonical links defined in your HTML. For example, setting this variable to 'true' ensures that a visitor to m.domain.com/index.html where the canonical link is set to 'domain.com/index.html' sends our servers a path of 'domain.com/index.html'. OR path: If you are unable or prefer to not use canonical links, you may alternatively set the Custom Path Variable. We highly recommend that you use a real path used to navigate to this page; example format: "domain.com/index.html" |
| Single Page Web Apps (virtual page change) |
path: We have a separate website implementation for tracking pages that are loaded dynamically without full DOM refresh. When calling our virtualPage function to track these page views, consistent page paths should be sent to us via the custom path variable. |
| Accelerated Mobile Pages |
canonicalPath: By default, our AMP integration captures the full page path value from the canonical link set in your AMP HTML. If you need to overwrite this value to ensure that your AMP pages send us page paths consistent with your standard website implementation, you can explicitly define this 'canonicalPath' variable in your Chartbeat AMP Analytics configuration. For example, if your AMP pages set canonical links to offsite URLs in your network like offsitedomain.com/index.html, your team can set the canonicalPath variable in your Chartbeat AMP configuration to the correct path, "correctdomain.com/index.html". |
| Facebook Instant Articles |
Our Facebook Instant Articles integration utilizes our basic web tracking code, so all of the same variables seen above for "Standard Web" are also available for use for this integration. |
| Native iOS & Android Applications |
viewId: This variable is the native app equivalent of our Custom Path variable detailed above for website integrations. Full path values including protocol, domain name and paths from the canonical web URLs, should be passed through this variable e.g. "https://domain.com/article/path". For further assistance with page paths sent from your mobile apps via our native app SDKs, please contact your Chartbeat Customer Success representative or support@chartbeat.com. |
Canonical links versus custom page paths
Google created the rel=canonical element years ago to help website owners consolidate duplicate URLs. It's considered best practice to set consistent canonical links across all of your web-based platforms and applications (desktop & mobile web, AMP pages, and Facebook IA), and keep these links unchanged for each unique page even as page titles are updated after an article has been published. If this is already in place for your web properties, we recommend following our default implementation instructions for each platform where Chartbeat code is implemented, making use of our useCanonical & useCanonicalDomain variables across all pages of your website to ensure that we receive the same path for a given article or landing page of your site wherever it lives.
If your analytics team cannot utilize canonical links for this purpose in your Chartbeat implementation (for example, canonical links are not implemented on your sites, or they are set to offsite URLs when stories are syndicated throughout your news network), we recommend utilizing the customizable path parameters identified above to ensure that your Chartbeat tracking strategy is configured to send uniform paths to our servers.
Identifying and correcting duplicate page path values in your Chartbeat code
If your team has identified duplicate page entries in your Chartbeat Real-Time or Historical dashboards, the next step is to review these troubleshooting steps with the group responsible for implementing Chartbeat tracking at your organization to identify the following:
- What are the different page paths that Chartbeat is receiving for each unique entry?
- Which of these paths does not match the expected URL format?
- Where in your Chartbeat tracking implementation are you sending page paths that do not match your expected Chartbeat page path format?
Here are some tips to get started answering these questions using your Chartbeat tools:
- In the Real-Time or Historical dashboard where the duplicate pages have been spotted, click into the page detail view for each entry and copy out the dashboard URL which contains in each a URL encoded version of the page path. For example:
[Real-Time]
https://chartbeat.com/publishing/dashboard/blog.chartbeat.com/?sortColumns=engaged_time::pageviews_today#path=2018.chartbeat.com%2Fstories
[Historical]
https://chartbeat.com/publishing/historical/blog.chartbeat.com/article/blog.chartbeat.com%2F2018%2F12%2F18%2Fmost-engaging-stories-2018%2F?pageHost=blog.chartbeat.com - For the dashboard entry where the path in our chartbeat.com URL appears in an unexpected format, evaluate the path format for clues about where in your tracking setup your code is sending ununiform page paths to our servers.
- If you are still having trouble determining the location of the implementation issue, evaluate the displayed traffic data in our dashboards in an effort to determine where in your Chartbeat tracking implementation the issue lies.
- If the traffic to the affected page is 100% desktop visitors, review your desktop site Chartbeat code for a problem in your page path configuration.
- If the traffic is 100% mobile with multiple traffic sources and visitor frequency types, review your mobile site Chartbeat implementation.
- If traffic is 100% mobile AMP and "unclassified" visitor frequency, review your AMP tracking configuration.
- If traffic is 100% mobile Facebook IA and all Social referred, review your Facebook IA configuration.
- If traffic is 100% mobile App where traffic is mostly Internal or Links referred, review your native app SDK implementations.
Once these questions have been answered, your analytics team should be equipped with the information included in this article to push a code change correcting the ununiform paths.