Ping is an analytics service that enables you to track remote web access across institutional web properties outside of Slate and correlate those accesses with records in Slate. Ping data is aggregated periodically every hour, and Ping access is matched to Slate records every night.
Ping provides a snippet of JavaScript code that is loaded when a user opens a web page where the code has been inserted.
If the user accesses a page using Ping for the first time and has not previously signed in to Slate on that computer, a persistent cookie is sent to the browser. This cookie contains a unique and random identifier that allows accesses from the same computer to be associated with one another. If the user has already accessed a page containing the Ping service or has accessed a resource within Slate, this cookie has already been set and does not need to be reset.
When the page loads, basic information about the page is collected (such as the URL and the date and time of access) and sent back to the server when the user leaves the page. Because this data is sent when the user leaves the page, the duration of the page access can be calculated and stored. Additional data points, including the IP address and the browser, are also stored. If the user is currently logged into Slate, this user ID is also stored.
Ping must be enabled to begin collecting data. Ping collects data from two types of sources:
- Internal, once activated on all Slate pages, including events and applications
- External, once the Ping code is placed in a webpage's HTML
To enable Ping on all Slate pages:
- Click Database.
- In the Configurations section, select Configuration Keys.
- In the Branding, Privacy, & Ping section, select Embed Ping on Slate Pages. A popup appears.
- From the dropdown, select Enabled.
- Click Save.
Important!
Enabling Ping on all Slate pages will not include forms.
To enable Ping on the external page where the form is embedded, refer to the following procedure.
To embed Ping tracking on any website outside of Slate:
- Click Database.
- In the Branding section, select Ping. The page includes a snippet of JavaScript.
- Copy the snippet.
- In your external webpage or template, open the HTML editor.
- Between the <head>...</head> tags, paste the snippet.
- Save.
Where should the Ping tracking code be placed on an HTML page?
While the Ping service will typically function regardless of where on an HTML page the code is placed, we recommend that the Ping code be placed immediately prior to the </head> close tag. This is also the advice of Google Analytics, and it does not matter whether Ping is placed before or after the Google Analytics or other JavaScript code in the <head>...</head> block.
Ping captures and stores the IP address and unique cookie associated with each web access. In some cases, the user may already be logged in to Slate (such as an application status page), and this identity may also be captured and stored. When a user opens an email sent through Slate or clicks on a link sent by email through Slate, this IP address and unique cookie are also captured and stored. When a user logs in to Slate, this IP address and unique cookie are also captured and stored. In the case of a Ping web access when a user is not logged in, the IP address and unique cookie alone (without any other data) would be insufficient in identifying a specific user in Slate. However, when combined with the data from email opens, clicks, and portal logins, all of which are associated with a specific recipient or user in Slate (an "authenticated event"), accesses through Ping that might otherwise be unidentifiable can be identified to a specific user. The authenticated event does not need to precede the web access recorded by Ping. For example, a user might access a financial aid web page as their first interaction with Ping or with Slate, and then, a month later, click a link in an email message. While the initial web page access would not be identifiable at that point in time, when the authenticated event was recorded, that same initial web page access could be identified back to the specific user.
In many regards, Ping is similar to Google Analytics or any other analytics service. Like these other services:
- Ping sets a cookie and records web accesses, including the page URL, IP address, browser, and cookie.
- Ping sends this data to a secure server.
- Ping enables an authorized user to query or report against this data.
- Ping enables accesses associated with a specific cookie or IP address to be associated with other activities or profiles similarly identified.
Ping differs from general analytics services that are intended to provide only aggregate information, in that:
- Ping uses the profile data from a web access to find matching profile data in authenticated events (email opens, clicks, and application page logins) and to associate the web accesses to a specific user based upon this matching profile data.
- Ping provides a view of the web accesses on a user-by-user basis.
- Ping provides querying and reporting on a user-by-user basis.
Like Google Analytics, Ping sets a cookie, records web accesses, and sends the data to a secure server.
However, the methods used for doing so are different enough that Ping hits may not correspond to pageviews in Google Analytics. For example:
- Google Analytics works on page load while Ping works on page unload, and unlike GA, a Ping hit isn't triggered until a student interacts with a page that has the Ping script embedded (for example, there is a touchmove, mousemove, click, or a keyup).
- With Ping, the data gets pushed back only when the page is unloaded, with the web server storing a cache that gets written back in batch to the database. As long as a student interacts with the web page, and as long as they refresh or close the tab, we would expect the Ping activity to be posted back successfully and inserted into the database. It's possible, however, that they close the tab in a different way or have cache control settings turned on in their browser in a way that prevents this. Additionally, if they have Do Not Track or similar markers enabled, Ping will respect this while GA will not.
For organizations residing in the United States, privacy policies for such analytics are not generally required as a matter of law. For organizations residing in a European Union country, the EU "Cookie Law" may direct an organization to disclose their use of cookies. The directive's requirements for an organization using Ping would typically be no different than for an organization using Google Analytics.
In nearly every case, an organization's existing privacy policy, if any, should be sufficient to support the use of Ping, provided the policy does not explicitly indicate that cookies will never be used to identify a specific user. (Such a privacy policy would likely already be incompatible with Slate independent of any use of Ping, because Slate, like any secure online service, must use cookies to track a login session.)
The techniques used by Ping are used by Google Analytics and commercial organizations throughout the United States and world.
These details do not constitute formal legal advice, and we advise that you consult your general counsel if you have any legal questions.
Each web access is individually captured and stored, enabling detail in a very granular way while also providing the data to be accessed in aggregate.
The Ping tracking code is unique for each school, and Ping only records web accesses on pages on which it has been specifically placed. The unique random cookie is different for each school using Slate, even if the same student is accessing multiple schools' web pages using the same computer. The Ping tracking code must be placed on each and every web page in order for it to track the accesses to those pages. The Ping tracking code can be added to a header or footer on a web site, enabling it to be run on all web pages on that web site, just as would be the case with Google Analytics or another analytics service.
The web accesses are stored in a [ping] table, and query filters and exports are available in the Slate Template Library which will facilitate access to this data within queries.
As present, there is no mandatory retention policy designated by Technolutions. This may be imposed at some point in the future for data storage or performance reasons. There will also be retention policy targets added to Slate specifically for Ping data.
Yes. Ping will not interfere with any other analytics services.
Ping is loaded asynchronously and reports its data back to the server asynchronously using sendBeacon method in supported browsers. Because these data operations occur asynchronously, there will be no performance impact to a web site, even in a situation where the Ping service may be unavailable or unreachable.
Ping Configurable Exports include:
- Total Duration (Seconds)
- Total Count
- Unique URL Count
- Last Timestamp
- First Timestamp
Ping Filters include:
- Ping by URL
- Ping Count by Timestamp
- Ping Count by URL, Timestamp
- Ping Duration by Timestamp
- Ping Duration by URL
Ping Destinations and Sources allow users to drill down into website paths for which Ping is in use. This functionality allows for the aggregate of reporting of counts per pathway, as well as the Source, Medium, and Campaign for each path. A date range can be specified to limit the overall reporting.
Yes, after linking a Facebook Ad account within the Deliver Configuration tool, a query identifying a targeted audience through Facebook Custom Audiences enables integrated ads and analytics between Slate and Facebook.