mirror of
https://github.com/Unleash/unleash.git
synced 2024-12-28 00:06:53 +01:00
d5fbd0b743
## What This (admittedly massive) PR updates the "physical" documentation structure and fixes url inconsistencies and SEO problems reported by marketing. The main points are: - remove or move directories : advanced, user_guide, deploy, api - move the files contained within to the appropriate one of topics, how-to, tutorials, or reference - update internal doc links and product links to the content - create client-side redirects for all the urls that have changed. A number of the files have been renamed in small ways to better match their url and to make them easier to find. Additionally, the top-level api directory has been moved to /reference/api/legacy/unleash (see the discussion points section for more on this). ## Why When moving our doc structure to diataxis a while back, we left the "physical' files lying where they were, because it didn't matter much to the new structure. However, that did introduce some inconsistencies with where you place docs and how we organize them. There's also the discrepancies in whether urls us underscores or hyphens (which isn't necessarily the same as their file name), which has been annoying me for a while, but now has also been raised by marketing as an issue in terms of SEO. ## Discussion points The old, hand-written API docs have been moved from /api to /reference/api/legacy/unleash. There _is_ a /reference/api/unleash directory, but this is being populated by the OpenAPI plugin, and mixing those could only cause trouble. However, I'm unsure about putting /legacy/ in the title, because the API isn't legacy, the docs are. Maybe we could use another path? Like /old-docs/ or something? I'd appreciate some input on this.
90 lines
5.4 KiB
Plaintext
90 lines
5.4 KiB
Plaintext
---
|
|
title: How to capture impression data
|
|
---
|
|
import ApiRequest from '@site/src/components/ApiRequest'
|
|
import VideoContent from '@site/src/components/VideoContent.jsx'
|
|
|
|
:::info Placeholders
|
|
Placeholders in the code samples below are delimited by angle brackets (i.e. `<placeholder-name>`). You will need to replace them with the values that are correct in _your_ situation for the code samples to run properly.
|
|
:::
|
|
|
|
Unleash allows you to gather [**impression data**](../reference/impression-data.md) from your feature toggles, giving you complete visibility into who checked what toggles and when. What you do with this data is entirely up to you, but a common use case is to send it off to an aggregation and analytics service such as [Posthog](https://posthog.com/) or [Google Analytics](https://analytics.google.com/), either just for monitoring purposes or to facilitate [A/B testing](../topics/a-b-testing.md).
|
|
|
|
This guide will take you through everything you need to do in Unleash to facilitate such a workflow. It will show you how to send data to Posthog as an example sink, but the exact same principles will apply to any other service of the same kind.
|
|
|
|
<VideoContent videoUrls={["https://www.youtube.com/embed/bxYdeMb9ffw"]}>
|
|
This content in this guide is also available in video format.
|
|
</VideoContent>
|
|
|
|
## Prerequisites
|
|
|
|
We will assume that you have the necessary details for your third-party service:
|
|
|
|
- **where to send the data to**. We'll refer to this in the code samples below as **`<sink-url>`**.
|
|
- **what format the data needs to be in**. This will determine how you transform the event data before you send it.
|
|
|
|
In addition, you'll need to have a toggle to record impression data for and an [Unleash client SDK](../reference/sdks/index.md) that supports impression data. This guide will use the [JavaScript proxy SDK](../reference/sdks/javascript-browser.md).
|
|
|
|
When you have those things sorted, follow the below steps.
|
|
|
|
## Step 1: Enable impression data for your feature toggle {#step-1}
|
|
|
|
Because impression data is an **opt-in feature**, the first step is to enable it for the feature you want to gather data from. You can use both the UI and the API.
|
|
|
|
### Enabling impression data for new feature toggles {#step-1-new-toggles}
|
|
|
|
When you create a new feature toggle via the UI, there's an option at the end of the form that you must enable:
|
|
|
|
|
|
|
|
To create a feature toggle with impression data enabled, set the `impressionData` option to `true` in the request payload, as seen below. For more options, check the [reference docs on creating features](/reference/api/legacy/unleash/admin/features-v2.md#create-toggle).
|
|
|
|
<ApiRequest verb="post" payload={{name: "<feature-toggle-name>", impressionData: true}} url="api/admin/projects/<project-id>/features" title="Create a feature toggle with impression data enabled."/>
|
|
|
|
### Enabling impression data for existing feature toggles {#step-1-existing-toggles}
|
|
|
|
To enable impression data for an existing toggle, go to the "Settings" tab of that feature toggle and use the "edit" button near the Feature information title in the admin UI. It will take you to a form that looks like the toggle creation form. Use the "Enable impression data" toggle to enable it, the same way you would when [enabling impression data for a new feature toggle](#step-1-new-toggles).
|
|
|
|
|
|
|
|
To enable impression data for an existing toggle, use the [API's toggle patching functionality](/reference/api/legacy/unleash/admin/features-v2.md#patch-toggle):
|
|
|
|
<ApiRequest verb="patch" payload={[{op: "replace", path: "/impressionData", value: true}]} url="api/admin/projects/<project-id>/features/<feature-toggle-name>" title="Enable impression data on an existing toggle."/>
|
|
|
|
|
|
## Step 2: Capture impression events in your client {#step-2}
|
|
|
|
In your client SDK, initialize the library for the third party service you're using.
|
|
For the full details on setting up a Posthog client, see [the official Posthog JavaScript client docs](https://posthog.com/docs/integrate/client/js).
|
|
The steps below will use extracts from said documentation.
|
|
|
|
After initializing the library, you'll probably also want to identify the current user, so that events can be correlated properly:
|
|
|
|
``` js title="Identify the user."
|
|
posthog.identify(userId);
|
|
```
|
|
|
|
### Capture and transform the event
|
|
|
|
Attach an event listener to Unleash that listens for `"impression"` events. Inside the listener, transform the event data to the format you want and send it to your analytics service.
|
|
|
|
``` js title="Capture, transform, and send impression data."
|
|
// listen for impression events
|
|
unleash.on("impression", (event) => {
|
|
|
|
// capture and transform events
|
|
posthog.capture(event.eventType, {
|
|
...event.context,
|
|
distinct_id: event.context?.userId,
|
|
featureName: event.featureName,
|
|
enabled: event.enabled,
|
|
variant: event.variant,
|
|
});
|
|
|
|
});
|
|
```
|
|
|
|
Posthog expects an object with a `distinct_id` property that it uses to correlate data.
|
|
Additionally, you can add whatever properties you want, such as the feature toggle name, its state and/or variant, or the whole Unleash context.
|
|
The `posthog.capture` method sends the event data to your Posthog instance.
|