- How do I know if I've installed the tag correctly?
- Will this tag break or slow down my site?
- What are the involved servers?
- How does Parse.ly handle staging/development sites?
- How are 'infinite-scroll' pages supported?
- How do I integrate Parse.ly on my mobile site?
- What about native iOS or Android mobile apps?
- How is HTTPS supported?
- How does tracking work?
- What data is sent by default?
- How does the service work with cookies?
- How does unique visitor counting work?
- Aside from the dashboard, how do I access the data sent to Parse.ly?
How do I know if I've installed the tag correctly?¶
You can validate the presence of the tracking code and that the metadata is correctly specified by checking the URL with the Validator.
Will this tag break or slow down my site?¶
Once our tracking code is loaded, we install a small cookie (just a user ID) and asynchronously beacon back information to our analytics server. If our analytics server is down, all that happens is that the actions are no longer tracked -- there is no impact on the user experience otherwise.
Check out our public Pingdom report showing our uptime and global response times.
What are the involved servers?¶
srv-*.config.parsely.com: configures publisher-specific settings
All of these hosts are distributed across multiple, global web servers and are also behind high-performance load balancers.
How does Parse.ly handle staging/development 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.
How are 'infinite-scroll' pages supported?¶
For some sites, the model of one Parse.ly tracking pixel per pageload isn't a perfect fit. This can happen if your site includes multi-page posts or galleries and you'd like each page of the post to send a pageview to Parse.ly. This situation also arises for sites that use "infinite scroll" - one webpage that continuously loads new posts as the user scrolls down.
to manually send pageload information to Parse.ly. The relevant call is
You might call this function when the user navigates to the next slide, or when they scroll down and a new article is loaded.
How do I integrate Parse.ly on my mobile site?¶
In general, integration for mobile web is identical to integration for desktop browsers. See the basic integration instructions for details.
What about native iOS or Android mobile apps?¶
We have open source iOS and Android toolkits for integrating tracking on these platforms.
How is HTTPS supported?¶
Parse.ly's tracker fully supports tracking on HTTPS pages. When tracking under HTTPS, Parse.ly's tracking tag automatically adapts the set of hosts used to ones with valid HTTPS certificates.
How does tracking work?¶
Upon a visit to a Parse.ly-tagged page, a code bundle is downloaded from Parse.ly's global content delivery network. This code bundle retrieves information about the visit to that page, such as pageview and time spent. When combined with metadata, information about your site streams into the dashboard and APIs.
What data is sent by default?¶
Several pixel fields are critical for Parse.ly to function at a basic level:
- url: current URL
- urlref: HTTP referrer (traffic source); can be blank
- action: action name (defaults to pageview)
- data: contains information on the UUID from cookie state
- idsite: the "site identifier", aka apikey, for the publisher
Other fields are also helpful, such as:
- title: page title
- screen: screen resolution information
- date: client-side datetime in the browser
These are sent in a standard HTTP request, which also includes client information such as the browser User-Agent, client IP address, and third-party (parsely.com) cookie settings.
How does the service work with cookies?¶
A separate service generates a Universally Unique Identifier, or UUID,
for the user. It stores this in a first-party cookie on your domain. It
also stores another cookie on your domain for the purpose of "sessionization",
or the association of several independent actions with a single visitor.
These cookies are called
Our system also attempts to create a third-party cookie for the purpose
of benchmarking your aggregated and anonymized visitor statistics against
other publishers. This cookie is called
is set on the
Users are able to opt out of our third-party cookie by visiting our
implemented by setting the third-party cookie's value to
instructs the rest of our system to disable analytics on that user.
For compliance with special regulations regarding cookies (e.g. in the EU region), we can enable special settings on your account; please contact us for more details on this.
PARSELY.config will allow you to inspect the cookie information sent
How does unique visitor counting work?¶
Our system stores a site-specific user identifier for the purpose of showing aggregated "unique visitor" counts in Parse.ly products. These visitor counts are stored in a format that divides them into "new" and "returning" visitors, as well as a format that combines new and returning into a generic "visitor" bucket.
In many cases, aggregate new and returning visitor counts will not add up exactly to the combined visitor count. There are two basic reasons for this.
Primarily, it is possible and common for the same user to be both new and returning within a given aggregation period. Imagine a user who visited your site for the first time ever yesterday, then came back again today. On their first visit, they were considered "new" by our system, and on the second visit they were considered "returning". Thus, when looking at new and returning visitor totals for the last two days in the Parse.ly dashboard, this user will be counted as both new and returning. This causes the sum of new and returning visitors to be greater than the combined visitor count stored in the database, since the combined count only counts each visitor once.
The other factor strongly affecting the summability of visitor counts is the way they're queried internally in our system. For query and storage efficiency, these sets of UUIDs are queried as approximate counts using an algorithm called HyperLogLog++. This algorithm trades a small amount of accuracy in counting unique visitors for query speed, meaning that the Parse.ly dashboard is able to show visitor counts alongside the rest of its realtime data. A side effect of this is a small error rate in the counts of new visitors, returning visitors, and total visitors. Thus, summing new and returning visitors is not expected to result in exactly the total visitor count, which itself contains some amount of inaccuracy. Rest assured, though, that the error rate incurred by this algorithm is small, usually hovering around 2%, and that approximate counting of unique visitors is in line with the industry standard.
Aside from the dashboard, how do I access the data sent to Parse.ly?¶
The dashboard includes a number of data access mechanisms, including:
- Excel/CSV exports on any listing screen
- Excel/CSV/HTML exports in the reporting suite
In addition to these dashboard-based data exports, you can also export data from Parse.ly via our HTTP/JSON API. This API is good for building site or CMS integrations. You can look at our API reference and API browser for usage examples.
If you need raw access to Parse.ly content/audience engagement data, including every unsampled event, you can license our Raw Data Pipeline. This will let you access compressed JSON files representing every event sent to Parse.ly via a secure Amazon S3 Bucket (bulk access) or Amazon Kinesis Streams (real-time streaming access). Our team can also help you integrate this data with open source and cloud technologies like Python, Spark, Google BigQuery, and Amazon Redshift.