Getting started with Parle

It takes 5 minutes to be up and running.

To start getting value from Parle, you’ll need to perform some integration on your application. You can start creating automation workflows, but until Parle starts receiving your users’ information, it won’t be able to initiate any workflow.

Available actions (v1.0):

You’ll need to decide what information to send regarding your users, depending on your workflow triggers and conditions. For instance, if you’re planning on having an automation workflow start based on feature usage or non-usage, you’ll need to track that feature usage and send the data to Parle.

If you’re only going to use the built-in triggers and conditions, you might be fine skipping tracking product usage. However, you won’t be able to see our product usage matrix. In short, you decide if and when you want to send more data to Parle.

Identify your users

This part is crucial and mandatory. Parle needs to know about your users.

As with all our API, you have the choice of using our embedded JavaScript script or calling our API via your backend. You may use a combination of both, depending on the situation.

Client-side identification

Your embed code is available in your [embed script page, it looks like this:

<script
  id="parle-embed"
  data-token="your-public-token"
  src="https://parle.io/embed/v1/parle.js"
></script>

Place this script at the end of your content, before the </body>.

To identify your users you call the identify function of the global parle object that got added via the embed script.

<script>
  parle.identify({
    id: 'your-user-identifier',
  email: 'their-email@domain.com',
  tags: ['optional', 'tag'],
  custom_fields: {
    number_of_user: 4
	}
	})
</script>

Field descriptions:

Field Is required Description
id required A unique identifier for this user
email required A valid email address for this user
tags optional A list of tags
custom_fields optional Key/value qualitative and quantitative data

The id and email fields are required. You may use whatever unique identifier you want for the id but keep in mind that it’s what Parle going to use to match this user from other actions from your application.

The tags and custom_fields are good meta information to add more details to a user.

note: The tags and custom_fields are append-only, meaning that omitting a tag won’t remove it from Parle’s tags for that user.

Server-side identification

If you prefer to use our API from your backend, you’ll need to generate at least one API key and use it for all your requests.

You can create your API keys in the API Keys tab on your settings page.

Here’s an example API call to identify a user:

$ curl \
  -H "Authorization: Bearer your-api-key" \
  -H "Content-Type: application/json" \
  -X POST \
  -D '{"USER": { "ID": "UNIQ_ID", "EMAIL": "A@B.COM", "TAGS": ["MY TAG"] }}' \
  https://app.parle.io/api/identify

The full JSON you can post is as follow:

{
  "user": {
    "id": "string",
    "email": "string",
    "tags": [],
    "custom_fields": {}
  },
  "company": {
    "id": "string",
    "name": "string"
  }
}

Once a user is identified, they will be eligible to be added to a workflow. Parle monitors this user and automatically adjusts their status based on their session frequency.

All users initially have an ‘ACTIVE’ status. Each status change can act as a workflow trigger, allowing you to react to users who may be slipping or churning.

Tags and custom fields can also be used as workflow triggers. Currently, you can only edit and remove tags within Parle.

Trigger events

Think of events as a straightforward way to trigger automation workflows. They differ from product usage tracking, as their sole purpose is to initiate a workflow.

There might be actions and specific events that occur in your application that you might want to use to trigger a workflow. For instance:

If you have a button in your application labeled ‘Try our new feature X’ and you’d like to initiate a workflow that enables this feature flag for the user and sends a series of four emails, triggering an event when the user clicks the button is all you need to enroll them in that feature’s workflow.

Another example could be when a user performs an action considered rare among your user base. You might want to start a workflow that prompts them for more details via an overlay and sends an email to connect with them, understand their reasons for using this particular part of the application, and potentially gain insights into why other users don’t use it.

Events are simply an easy way to start an automation workflow.

Client-side event triggering

parle.trigger("event-id");

Note: You’ll need to identify a user before you can trigger an event for them.

Trigger events that don’t match any active workflow are simply ignored.

Server-side event triggering

$ curl \
  -H "Authorization: Bearer your-api-key" \
  -H "Content-Type: application/json" \
  -X POST \
  -D '{ "id": "user_uniq_id", "trigger_id": "id-of-event" }' \
  https://app.parle.io/api/trigger

You can find the trigger_id in your events list here.

Track usage

Tracking your product usage offers valuable insights into how frequently your features are used and their popularity among your user base.

While taking the time to track important actions might seem like an initial drawback, the insights you’ll gain can be well worth the effort. We will generate a feature matrix graph, allowing you to quickly identify underutilized features and spot important trends in how your users actually interact with your product.

Product usage data can also trigger automation workflows. For example, you could set up a sequence of emails and in-app messages for users who haven’t yet used one of your main features.

You might also want to engage with high-usage users and invite them to be part of your premium group, where they can test new features and provide feedback.

The knowledge you gain by understanding how your users interact with your product is invaluable for your future development and strategy.

Client-side usage tracking

parle.track("workflow created", "automation");

We recommend using the format ’noun past-tense-verb’ for the action being tracked. For example, ‘project created’ or ’teammate invited’.

The second argument represents the broad feature category. In the code sample, ‘workflow created’ is used. For Parle, a key indicator of a user actively using our product and gaining value is whether they are creating workflows. This feature falls under our ‘automation’ category.

Avoid tracking every single user action, as this will reduce the quality and usefulness of the insights you gain.

Instead, focus on identifying around 6 to 12 crucial actions a user needs to perform at some point in their journey to achieve success. Carefully consider these actions before deploying your integration; this is important.

Remember that you have tags and custom fields available to apply both quantitative and qualitative data to a user. Don’t view product usage tracking primarily as a way to segment your users.

Ask yourself when you would want to engage a user if they are not performing a specific action. These scenarios typically represent good starting points for tracking. You can always add more tracking later.

Server-side usage tracking

$ curl \
  -H "Authorization: Bearer your-api-key" \
  -H "Content-Type: application/json" \
  -X POST \
  -D '{ "id": "user-uniq-id", "action": "workflow created", "feature": "automation" }' \
  https://app.parle.io/api/track