Overview
Security and privacy questions are often top of mind anytime information is shared with a third party. User data and other identifying information can be highly sensitive. Pendo hosts your application data in a secure multi-tenant environment, and is designed to give you full privacy control with your user data.
To work effectively, the only critical information that Pendo needs is a unique identifier for each user in your application. This does not have to include any personally identifiable information for the user or the account, merely a unique identification. Most Pendo users do end up passing additional information such as an email or account name, along with other demographic information to help build out segments, but this is not required.
The Pendo platform does not collect any user-entered text or information within form fields in your application. By default the names of fields, buttons, and other elements within the page are captured with the application data which makes for easier tracking, but no user-supplied information is included.
Note: While it is possible to disable all text capture within the API, this can potentially limit the use of historical data for Feature tagging.
Pendo’s application and data are hosted and stored in Google’s AppEngine where they share the same infrastructure as Google’s primary services. The AppEngine allows Pendo to operate in a robust, fully multi-tenant infrastructure with the same reliability, performance, and security characteristics as Google’s own offerings. Google AppEngine is SOC 2, ISO 27001, FISMA, and PCI compliant, and Google completes multiple independent security audits annually.
All of the application data collected by Pendo is transmitted over SSL, encrypted at rest, and stored for each customer using separate AppEngine namespaces to ensure that no data is co-mingled.
Users may alternatively request Pendo disable password-based logins and require authentication via either (a) SAML based authentication (e.g., Okta, Azure AD, Duo), or (b) Google-based logins or if their Google email and Pendo login addresses match. Both (a) and (b) support two factor authentication via the chosen identity provider.
What Data Does Pendo Collect?
The Pendo Launcher is a Google Chrome extension that allows your employees to launch a Resource Center within their web-based applications. The Resource Center (formerly the Guide Center) houses additional in-context help that you can make readily available to your end users. Companies can configure the Pendo Launcher to collect as little or as much metadata (which may or may not include personally identifiable information) as they wish and can then utilize this data to provide users with in-app guidance. Fundamentally, the Pendo Launcher collects data in the same way as Pendo Engage, Pendo’s product which enables companies to improve their users experience with their software via in-app guidance and analytics. All that is required is a unique identifier, but customers may use Pendo to collect additional metadata, including personally identifiable information if they so choose. Event data collected using the Pendo Launcher is sent to Pendo's backend and is stored and processed in Google Cloud Platform (GCP).
Typically, a customer's IT department (in collaboration with the customer's business stakeholders, as applicable) determines what, if any, metadata they would like Pendo to collect and configures the Launcher accordingly.
Metadata can be used to create segments for guide targeting, as well as general analysis. Common metadata attributes customers can pass include: User Role, Price Plan, E-mail Address, Account Creation Date, etc.
Additionally, customers can explicitly avoid collecting metadata about employees by setting them as anonymous.
Note: When customers are determining whether to set employees to anonymous in Pendo, and not collect metadata, they should consider how they intend to segment, target guides, etc.
Setting up “Applications”
Data is captured by the Pendo Launcher through Javascript code which runs inside of the browser of your web application. However, the Javascript code, which collects usage data, only runs on webpages that have been configured by a customer's IT department. IT departments can deploy the Pendo agent onto specific web pages by adding a webpage’s URL to the “domain patterns '' field on a New Extension Application form in the Adopt UI. This allows the customer to specify one or more hostnames in which the extension should deploy the agent.
For instance, a customer could specify “company.acme.com” as a “domain pattern”. This would tell the extension to deploy the Pendo agent on any URL that matches “company.acme.com” explicitly. This would typically include a site’s landing page as well as its subpages. These pages often appear as drop downs in a top navigation bar or sidebar menu.
This filtering is specifically managed by an extension API, webNavigation. The extension uses an onCommitted hook (webNavigation.onCommitted - Mozilla | MDN ) to watch for url changes, and then passes the resulting url through a UrlFilter (events.UrlFilter - Mozilla | MDN ). This ensures that the extension won’t inject the agent onto pages that do not specifically match the customer’s provided set of hostnames.
EU vs. US Metadata Collection
Customers can distinguish users in Adopt based on geography through their preferred IT tooling system. For example, if a customer needed to deploy the extension differently for people in the UK, that would happen entirely outside of Pendo.
Customers can also have their data hosed in our EU data centers. To do this, customers can configure their IT rollout to point to EU via the dataEnvironment IT config key, which can be set as "dataEnvironment": "eu" in the JSON script which defines the deploy settings for a user. For example:
<key>dataHost</key> <string>eu</string>