feature/add-journey-models - #84
Conversation
fivetran-avinash
left a comment
fivetran-avinash
left a comment
There was a problem hiding this comment.
@fivetran-savage Looking good! A few suggestions and comments to take a look at.
| @@ -0,0 +1,5 @@ | |||
| id,name,journey_type,description,creator_user_id,enabled,is_archived,lifetime_limit,simultaneous_limit,start_tile_id,trigger_event_names,created_at,updated_at,_fivetran_synced,draft_name | |||
There was a problem hiding this comment.
journey_type in the seed data is indicated as Published/Draft in the API docs, should we use those values? I notice those in a few sample schemas as well.
There was a problem hiding this comment.
We pull campaign_state into the end model, which includes both draft and aborted campaigns.
| - name: journey_name | ||
| description: User defined name of the journey | ||
| - name: journey_type | ||
| description: The journey type |
There was a problem hiding this comment.
Similar comment as src_iterable.yml
| -- numerator and denominator events are present in the `iterable__event_metrics` variable, | ||
| -- since that list is user-configurable and may not include every email event. | ||
| {%- set rate_expressions = [] %} | ||
| {%- if 'emailsend' in event_metrics %} |
There was a problem hiding this comment.
The email_open_rate/click_rate/bounce_rate/unsubscribe_rate calculations divide total_emailopen/total_emailclick/etc by total_emailsend. But since users can re-enter the same journey multiple times (based on the lifetime_limit definition), campaigns can recur, and a single email could potentially be opened/clicked more than once, these rates could end up over 100%.
Should we consider using the unique_total_* columns (already computed alongside the raw totals in int_iterable__journey_event_metrics) for both the numerator and denominator instead, so the rate reflects distinct users and stays properly bounded?
(We could consider other metrics for the raw event counts if we want to utilize them too).
There was a problem hiding this comment.
Fair point and worth considering. Makes journeys a bit different from campaigns in the way metrics can/should be calculated, potentially.
There was a problem hiding this comment.
I'm wondering if we should be calculating rates at all? Looks like iterable__campaigns doesn't calculate these metrics, so maybe we should leave the raw event counts for users to calculate metrics in their own BI tools.
fivetran-data-model-bot
removed
the
docs:ready
…ran/dbt_iterable into feature/add-journey-models
Co-authored-by: Avinash Kunnath <108772760+fivetran-avinash@users.noreply.github.com>
fivetran-data-model-bot
removed
the
docs:ready
fivetran-avinash
left a comment
fivetran-avinash
left a comment
There was a problem hiding this comment.
@fivetran-savage Approved with some final minor comments!
Co-authored-by: Avinash Kunnath <108772760+fivetran-avinash@users.noreply.github.com>
fivetran-savage
added
docs:ready
3 participants
PR Overview
Package version introduced in this PR:
This PR addresses the following Issue/Feature(s):
Summary of changes:
iterable__journeysend model, a journey-grain rollup of engagement metrics, unique users, and derived rates.journey_id,journey_name, andjourney_typetoiterable__campaigns.stg_iterable__journeysource table.Submission Checklist
Changelog