DO:

• Use consistent naming conventions
• Ensure activity features are specific to that activity (only)
• Use enrichment tables sparingly
• Model your activities on top of source data, not transformed data
• Chat with the Narrator team when you have questions!

DON'T:

• Spend more than 15 minutes writing a transformation
• Use timestamps as features
• Use customer attributes as activity features
• Change the activity slug after it's been defined
• Define time-based features or activity names in the activity definition

DOs

DO: Use consistent naming conventions

Since everything in the activity stream is from the perspective of the customer, your activities should be too. This will come in handy when you're creating auto-generated analyses in Narrator too. We recommend using a consistent naming convention like the following:

Convention: verb_noun (snake case)

• created_account
• added_user
• updated_profile
• submitted_ticket

Note: search will be easier if you don't use filler works like a and the. Ie. create an activity named added_user instead of added_a_user.

DO: Ensure activity features are specific to that activity (only)

Keep your activities cleaner by ensuring the features are specific to that activity.
You can always combine features from other activities when using them in dataset, so it's best practice to ensure your activity features are specific to that activity, and only that activity. For example, instead of adding first_touch_ad_source as feature on your submitted_lead activity. You can combine the FIRST EVER Started Session's Ad Source with the Submitted Lead activity in dataset. Learn more about borrowing features from other activities in dataset here.

DO: Use enrichment tables sparingly

Enrichment tables should be used sparingly because they can slow down your queries when you need to use them in a dataset. Only create an enrichment table when the activity needs many features that CANNOT be associated with another activity. Learn more about when to create enrichment tables.

DO: Model your activities on top of source data, not transformed data

It's best practice to model activities on top of source data. This is because of two reasons: 1) Narrator uses incremental updates by default, which means that changes to historical data will not get picked up when data changes. 2) Any bugs and changes in data structure will be perpetuated in Narrator. Part of the benefit of Narrator's data model is that the definitions are simple and easy to follow to the source of truth. In debugging if you have to also debug additional transformations under the hood, it creates additional complexity.

DO: Chat with the Narrator team when you have questions!

We're here to help! Please reach out to our team if you have any questions at all. A member of our data team will answer your question, and you'll be able to move forward faster.

DON'Ts

DON'T: Spend more than 15 minutes writing a transformation

Transformations should be simple SQL queries. If you find yourself spending >15 minutes on any transformation, it's likely a sign that you should stop and ask for help. Our support team is available if you have any questions, just reach out and we can help you work through it.

DON'T: Use timestamps as features

If you're tempted to use a timestamp as a features, you're likely better served creating a dedicated activity for the timestamp you're adding. Narrator's data model is meant to represent actions in time, so two timestamps should never need to be recorded on the same activity.

DON'T: Use customer attributes as activity features

You can use a customer table for this. Customer attributes can be added to any activity in a dataset, so you don't need to add them as activity features. Learn more about customer tables.

DON'T: Change the activity slug after it's been defined

The activity slug is the string that you define for the activity column value (ex. "submitted_lead"). If you modify this slug after it's been pushed to production, all downstream references to this activity (like in datasets) will break. Rename it in the activity details page instead. This will update the activity name everywhere it shows up in Narrator while maintaining all downstream dependencies.

DON'T: Define time-based features or activity names in the activity definition

Examples of this mistake:

• Activity Name: first_sign_up
• Feature: days_since_last_login
• Feature: first_touch_ad_source

These features are time-based since terms like first and last are relative references based on time. Narrator was built to handle this kind of logic, but within a dataset, not the activity definition. This is why it's best practice to compute all time-based references within a dataset by leveraging relationships to define any first..., last..., days since.... columns.

Still have questions?

Our data team is here to help! Here are a couple ways to get in touch...

💬 Chat us from within Narrator

💌 Email us at [email protected]

🗓 Or schedule a 15 minute meeting with our data team