|
1 | | -# Event tracking |
| 1 | +# Event tracking with Datadog |
2 | 2 |
|
3 | | -Eppo's Track API allow you to record any actions your users perform, like "Signed Up", "Made a Purchase" or "Clicked a Button", |
4 | | -along with any properties that describe the action. Once you send these events, Eppo will ingest them, batch, process and load into your data warehouse. You can then use those events in your warehouse to run experiments, construct data pipelines, or power custom tools/dashboards. |
| 3 | +:::info Deprecation Notice |
| 4 | +Eppo's native event tracking feature has been deprecated in favor of integrating with Datadog's RUM SDK and product analytics platform. This approach provides more robust analytics capabilities and better integration with your existing observability stack. |
| 5 | +::: |
5 | 6 |
|
6 | | -## Benefits of using the Track API |
| 7 | +Eppo now recommends using [Datadog's RUM (Real User Monitoring) SDK](https://docs.datadoghq.com/real_user_monitoring/) and [product analytics platform](https://docs.datadoghq.com/product_analytics/) to track user events and behaviors for experiment analysis. This integration allows you to leverage Datadog's powerful analytics capabilities while maintaining seamless experiment tracking with Eppo. |
7 | 8 |
|
8 | | -* **Deeper Insights**: You can better understand how people use your product. That helps you figure out where users might get stuck, what features they love, and what drives them to come back. |
9 | | -* **Personalized Experiences**: Once you know what actions users are taking, you can customize their experience—like sending personalized messages or recommending features they’d find useful. |
10 | | -* **Consistent Data Flow**: By centralizing your event tracking with an API call, you keep everything neat and standard across all your different tools (analytics, CRM, marketing platforms, etc.). |
| 9 | +## Benefits of using Datadog for experiment tracking |
11 | 10 |
|
12 | | -## When to Use It |
| 11 | +* **Unified observability**: Combine experiment data with your existing application monitoring, logs, and traces in a single platform |
| 12 | +* **Advanced analytics**: Leverage Datadog's sophisticated funnel analysis, retention tracking, and user journey mapping |
| 13 | +* **Real-time insights**: Get immediate visibility into how experiment variations affect user behavior |
| 14 | +* **Scalable infrastructure**: Built to handle high-volume event tracking without performance impact |
| 15 | +* **Rich visualizations**: Create custom dashboards and reports for experiment results and user behavior |
13 | 16 |
|
14 | | -Use the Track API any time you want to record a user’s action. This could be: |
| 17 | +## Getting started |
15 | 18 |
|
16 | | -* User signs up or completes onboarding; |
17 | | -* User views specific screens or pages; |
18 | | -* User interacts with certain in-app features (clicking a button, changing a setting, etc.); |
19 | | -* Transactions, such as making a purchase or completing a subscription upgrade; |
| 19 | +### 1. Set up Datadog RUM SDK |
20 | 20 |
|
| 21 | +First, install and configure the Datadog RUM SDK for your platform. Follow the platform-specific setup guides: |
21 | 22 |
|
22 | | -## Example usage |
23 | | -Events are composed of a `type` string, and a `payload`. The `payload` can contain any properties you'd like to associate with the event. The maximum length of the stringified JSON `payload` is 4096. |
| 23 | +- [Browser RUM SDK](https://docs.datadoghq.com/real_user_monitoring/browser/) |
| 24 | +- [Mobile RUM SDK (iOS)](https://docs.datadoghq.com/real_user_monitoring/mobile_and_tv_monitoring/setup/ios/) |
| 25 | +- [Mobile RUM SDK (Android)](https://docs.datadoghq.com/real_user_monitoring/mobile_and_tv_monitoring/setup/android/) |
| 26 | +- [React Native RUM SDK](https://docs.datadoghq.com/real_user_monitoring/mobile_and_tv_monitoring/setup/reactnative/) |
24 | 27 |
|
25 | | -Here's an example of how you might use the Track API in a Browser application: |
| 28 | +### 2. Track experiment-relevant events |
26 | 29 |
|
27 | | -```typescript |
28 | | -import * as EppoSdk from "@eppo/js-client-sdk"; |
| 30 | +Use Datadog's custom event tracking to record user actions that are relevant to your experiments: |
29 | 31 |
|
30 | | -const eppoClient = EppoSdk.getInstance(); |
31 | | -eppoClient.track("added_to_cart", { |
32 | | - productId: "abc-987", |
33 | | - userId: "123", |
34 | | - price: 24.99 |
| 32 | +```javascript |
| 33 | +// Browser example |
| 34 | +import { datadogRum } from '@datadog/browser-rum'; |
| 35 | + |
| 36 | +// Track a custom event |
| 37 | +datadogRum.addAction('button_clicked', { |
| 38 | + button_id: 'signup_cta', |
| 39 | + user_id: 'user_123' |
35 | 40 | }); |
36 | 41 | ``` |
37 | 42 |
|
38 | | -## Data Organization |
39 | | -When configuring Eppo for experimentation, you provide Eppo with a dataset/schema to use for writing intermediate tables for experiment analysis. We use this same dataset for writing events logged by our SDKs. This ensures maximum performance when using metrics based on these events in experiment analysis. |
40 | | - |
41 | | -### Events table |
42 | | -By default, each event `type` will be stored in a single table called `eppo_events`. This table contains the following fields: |
43 | | -| Column Name | Type | Description | |
44 | | -|-------------|------|-------------| |
45 | | -| `timestamp` | `TIMESTAMP` | When the event was created/tracked (populated automatically) | |
46 | | -| `type` | `VARCHAR` | Type of the event | |
47 | | -| `payload` | `VARCHAR` | Payload of the event in JSON format | |
48 | | -| `uuid` | `VARCHAR` | UUID of the event (populated automatically) | |
49 | | -| `api_key_prefix` | `VARCHAR` | Prefix of the SDK key used to log the event (populated automatically) | |
50 | | -| `client_ip_fingerprint` | `VARCHAR` | Fingerprint of the IP address of the client that logged the event (populated automatically) | |
51 | | -| `environment` | `VARCHAR` | Environment of the event (populated automatically based on the SDK key used) | |
52 | | - |
| 43 | +```swift |
| 44 | +// iOS example |
| 45 | +import DatadogRUM |
| 46 | + |
| 47 | +// Track experiment-related user action |
| 48 | +RUMMonitor.shared().addAction( |
| 49 | + type: .custom, |
| 50 | + name: "purchase_completed", |
| 51 | + attributes: [ |
| 52 | + "purchase_amount": 29.99, |
| 53 | + "user_id": "user_456" |
| 54 | + ] |
| 55 | +) |
| 56 | +``` |
53 | 57 |
|
54 | | -### Custom tables |
55 | | -You can also configure a certain event `type` to be stored in its own table, with a specific schema. Rather than having a single column that contains the `payload` sent to the SDK, custom tables can have specific events which are extracted from events in the `payload`. |
| 58 | +## Integration with Eppo Assignment data |
56 | 59 |
|
57 | | -For example, consider the following event: |
| 60 | +### Using the official Datadog-Eppo integration |
58 | 61 |
|
59 | | -``` |
60 | | -{ |
61 | | - "type": "item_added_to_cart", |
62 | | - "payload": { |
63 | | - "user_id": "user_123", |
64 | | - "item_id": "item_456", |
65 | | - "item_name": "Some Widget", |
66 | | - "price": 10.00, |
67 | | - "currency": "USD" |
68 | | - } |
69 | | -} |
70 | | -``` |
| 62 | +Datadog provides an official integration with Eppo that automatically enriches your RUM data with feature flag information. This integration provides visibility into performance monitoring and behavioral changes by showing which users are exposed to which variations. |
71 | 63 |
|
72 | | -This event can be configured to be stored in a custom table, with each field in the payload represented as a column in the table. The resulting table will have the following structure (with underlying types depending on your warehouse): |
73 | | -| Column Name | Type | Description | |
74 | | -|-------------|------|-------------| |
75 | | -| user_id | `VARCHAR` | ID of the user who added the item to the cart | |
76 | | -| item_id | `VARCHAR` | ID of the item added to the cart | |
77 | | -| item_name | `VARCHAR` | Name of the item added to the cart | |
78 | | -| price | `DECIMAL` | Price of the item added to the cart | |
79 | | -| currency | `VARCHAR` | Currency of the item added to the cart | |
80 | | -| timestamp | `TIMESTAMP` | When the event was created/tracked (populated automatically) | |
81 | | -| uuid | `VARCHAR` | UUID of the event (populated automatically) | |
82 | | -| api_key_prefix | `VARCHAR` | Prefix of the SDK key used to log the event (populated automatically) | |
83 | | -| client_ip_fingerprint | `VARCHAR` | Fingerprint of the IP address of the client that logged the event (populated automatically) | |
84 | | -| environment | `VARCHAR` | Environment of the event (populated automatically based on the SDK key used) | |
| 64 | +To set up the integration, follow the [official Datadog-Eppo integration documentation](https://docs.datadoghq.com/integrations/eppo/). The setup involves: |
85 | 65 |
|
86 | | -Once a table is configured, the schema can only be modified in a backward-compatible manner. This means that you cannot remove or change columns, but you can add new columns. |
| 66 | +1. **Update your RUM SDK**: Ensure you're using Browser RUM SDK version 4.25.0 or above |
| 67 | +2. **Enable feature flags**: Configure the `enableExperimentalFeatures` parameter with `["feature_flags"]` when initializing the RUM SDK |
| 68 | +3. **Configure Eppo SDK**: Initialize Eppo's SDK with the assignment logger that reports to Datadog |
87 | 69 |
|
| 70 | +This integration automatically tracks feature flag evaluations and provides rich visualizations in your Datadog dashboards, showing how experiments impact user experience and performance metrics. |
88 | 71 |
|
89 | | -## System latency |
90 | | -Events tracked with our SDKs are buffered to local storage on the user's device (or server, depending on the SDK) before being sent in batches to Eppo's servers. We then do additional batching before writing the results into your warehouse. |
| 72 | +Continue using Eppo's Experiment Analysis for calculating statistical signicance and confidence intervals with metrics from your warehouse. |
91 | 73 |
|
92 | | -The frequency of updates/latency depends on the load/availability of compute resources in your warehouse. You are able to configure how often, and optionally during what times of day events are loaded into your warehouse. The maximum frequency which you are able to configure events to be loaded into your warehouse is 10 minutes. |
| 74 | +## Data organization and querying |
93 | 75 |
|
| 76 | +Events tracked through Datadog RUM are automatically organized and can be queried using [Datadog's query language](https://docs.datadoghq.com/logs/explorer/search_syntax/). You can: |
94 | 77 |
|
95 | | -## SDK Configuration |
96 | | -In order to use the Track API in the Eppo SDKs, you need to use an SDK key which was created after November 15, 2024. SDK keys created prior to this date can still be used for feature flag/experiments, but not event tracking. |
| 78 | +- Filter events by experiment key and variation |
| 79 | +- Aggregate metrics across experiment cohorts |
| 80 | +- Create custom metrics based on experiment performance |
| 81 | +- Set up alerts for real time experiment-related anomalies |
97 | 82 |
|
98 | | -Other than using a compatible SDK key, there is no additional configuration required. Simply initialize the SDK with your SDK key, and start tracking events. |
| 83 | +## Best practices |
99 | 84 |
|
100 | | -In order to override the default behavior of certain aspects of event handling, you can modify the following properties (see language-specific pages for examples): |
| 85 | +1. **Consistent naming**: Use consistent naming conventions for experiment keys and event types |
| 86 | +2. **Include context**: Always include relevant experiment metadata with your events |
| 87 | +3. **Monitor performance**: Use Datadog's performance monitoring to ensure event tracking doesn't impact user experience |
| 88 | +4. **Set up alerts**: Create alerts for unusual patterns in experiment metrics |
| 89 | +5. **Regular cleanup**: Remove tracking for concluded experiments to maintain data hygiene |
101 | 90 |
|
102 | | -| Property | Type | Description | Default | |
103 | | -|----------|------|-------------|---------| |
104 | | -| `deliveryIntervalMs` | `number` | Time to wait between each batch delivery, in milliseconds. | 10,000 (10 seconds) | |
105 | | -| `retryIntervalMs` | `number` | Minimum time to wait before retrying a failed delivery, in milliseconds. | 5,000 (5 seconds) | |
106 | | -| `maxRetryDelayMs` | `number` | Maximum time to wait before retrying a failed delivery, in milliseconds. | 30,000 (30 seconds) | |
107 | | -| `maxRetries` | `number` | Maximum number of retry attempts before giving up on a batch delivery. | 3 | |
108 | | -| `batchSize` | `number` | Maximum number of events to send per batch/network request. | 1,000 | |
109 | | -| `maxQueueSize` | `number` | Maximum number of events to queue in memory before starting to drop events. | 10,000 | |
| 91 | +For detailed implementation guides and advanced features, refer to the [Datadog RUM documentation](https://docs.datadoghq.com/real_user_monitoring/) and [product analytics documentation](https://docs.datadoghq.com/product_analytics/). |
0 commit comments