All Collections
Developer's introduction to
Developer's introduction to

Developer-oriented introduction of

Updated over a week ago

This guide provides comprehensive information to kickstart your journey with implementation and directs you to additional resources based on your specific requirements.

What does do? is a product-led growth platform that empowers Growth, Product, RevOps, Sales, and Customer Success teams to identify and act on conversion, expansion, and upsell opportunities, as well as potential churn risks. To achieve this, our platform offers the following capabilities:

  • Centralizes usage and customer data from SaaS platforms, websites, CRMs, and third-party applications, offering a complete view of customer behavior.

  • Reveals insights into the elements (features, screens, webpages, channels, campaigns, etc.) that drive lead conversions, customer expansions, and potential churn.

  • Notifies accounts and users meeting customer-defined criteria based on previous insights.

  • Integrates with downstream applications to automate workflows.

  • Organizes platform data within appropriate inboxes, facilitating collaboration across different teams in the context of customer engagement.

injecting platform data to's SDKs generate and transmit messages to our tracking API in JSON format, providing a standardized structure for essential API calls. Additionally, we offer recommended JSON structures (referred to as "schemas" or "Specs") that maintain consistency in crucial data elements while allowing flexibility in collecting other information. These specs are 100% compatible with's specs, ensuring easy portability between both platforms.

There are five calls in the basic tracking API, which answer specific questions:

  • Who is the user? (Identify call)

  • What are they doing? (Track call)

  • What web page are they on? (Page call without a name, URL-based)

  • What app screen are they on? (Page call with a name)

  • What account, company, workspace or organization are they part of? (Group call)

Identify and Group calls are akin to inserting and updating a user's record/account's in a database, while Track and Page calls represent events, each generating separate records.

The latter two can also be considered as increasingly specific types of events. Events can occur multiple times, but generate separate records which append to a list, instead of being updated over time.

A Track call is the most basic type of call, and can represent any type of event. A Page call is similar and is triggered by a user viewing a page (or screen). Pages without a name typically comes from viewing webpages and is based solely on URL, while pages with a name ("Screens") typically occur in an app, where each user potentially navigates a different URL containing e.g. its platform ID.

A page without a name is solely referred to its URL
A Screen (page with name) could be referred to as "Dashboard", while his URL is{ID}/Dashboard.

Anatomy of a message

A fundamental message necessitates only a userID or anonymousID; all other fields are optional for maximum flexibility. However, a typical message comprises three main parts: common fields, context, and metadata (for events) or traits/properties (for objects).

  • Common fields: Includes call-specific information like timestamp, library name, and version.

  • Context: Contains details about the environment in which the call originated, such as page path, user agent, OS, and locale settings.

  • Event metadata/traits/properties: Optional and customizable, allowing you to define the data to collect for your implementation.

Message schemas, Blocks, and Specs "Specs" (fully compatible with specs) offer recommended message schemas for various call types. While these are suggestions rather than requirements, adhering to these schema guidelines enables servers to more effectively interpret and transmit your messages to downstream tools.

In addition to message schemas, provides "blocks," which recommend what information to collect and how to format it, tailored to different industries and use cases. These are also suggestions, but following these recommendations ensures that common tools used in specific use cases can function optimally.

Planning your implementation

Embarking on a successful journey often begins with a well-thought-out plan. Whether you're a new company implementing a PLG platform for the first time or a multinational corporation modernizing your stack, it's beneficial to start with a tracking plan. For new implementations, this plan can be as simple as a document outlining the following details for each item you intend to track:

  • What am I tracking? (Event name or type)

  • Why am I tracking it? (The questions this data answers)

  • For whom am I tracking it? (Ownership within the organization or specific tool/business area)

Did this answer your question?