Integration: Staging / dev sites

It’s common for websites to use a staging (also called “development”) environment to test code and preview posts before they’re released publicly. Often, these sites are implemented as subdomains of the site domain.

Including the Parse.ly JavaScript with a production Site ID on such a staging site can cause problems with the numbers that Parse.ly reports, the validator tool, the link between URLs and posts in Parse.ly’s analytics engine, and more. This is because staging URLs often disappear or change without warning, and are typically not accessible to the public.

Reach out to support@parsely.com to receive a sandbox Site ID that you can use for testing purposes.

Can I test Parse.ly on a staging/dev site?

Testing Parse.ly on a Staging/Development Site

You can! The best way to test Parse.ly on a staging/dev site is to reach out to your account manager or support@parsely.com to set up a separate sandbox dashboard and Site ID. When you integrate Parse.ly tracking on your staging/dev site, make sure you set the Site ID to the sandbox Site ID associated with the staging dashboard. This will help avoid staging URLs showing up in your production dashboard and API results. Additionally, articles can be tested before they are published on your live site using a sandbox dashboard.

You should only send pageviews to a production dashboard for URLs that appear on your live site, or that you want to appear in your dashboard and API results. Creating a separate sandbox dashboard to track staging pages is a better approach.

Troubleshooting Staging/Development Tracking Issues

Seeing posts in the Parse.ly dashboard associated with staging/development URLs is likely a result of Parse.ly tracking code on a staging/development site with the Site ID set to your production site. If the tracking code is already integrated this way on your staging/development site but you would like to remove the staging/development post pages from Dash, please contact your account representative or support@parsely.com. They can help block the reception of pageview and heartbeat events from specific subdomains such as your staging/ development site.

Another common source of data inconsistency occurs when publishers fire pageviews from a staging/dev site to a production dashboard with URLs for articles that haven’t yet been published. For example, the page staging.example.com/article1 fires a Parse.ly pageview for the URL example.com/article1 (the URL on the production site, which has yet to go live).

After blocking the reception of additional events from your staging/development site, we will attempt to remove the posts associated with staging/development sites from our records, and then update the traffic data in the Parse.ly dashboard to reflect the changes.