counterweight/data-dwh-dbt-project
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Merged PR 2028: guest journey estimated completed date

Browse source 
This PR includes the logic to handle the completed date of guest journey

Check the schema file to understand the logic implemented. It's an estimation, and in some cases, weird stuff happens on end dates before link usage dates, which effectively breaks the computation. I added a boolean for this

Related work items: #17268
This commit is contained in:
Oriol Roqué Paniagua 2024-06-13 13:30:22 +00:00
parent 6b4490b017
commit 7914d7d8d7
4 changed files with 126 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

49
models/intermediate/core/schema.yaml
View file

@ -266,3 +266,52 @@ models:
if the verification request can be considered as completed and all confirmed verifications are from
previous verification requests.
- name: int_core__verification_request_completed_date
description: |
The `int_core__verification_request_completed_date` model allows to retrieve the time in which the guest
journey, or verification request, was completed. It only considers that a guest journey is completed based
on the positive outcome of the is_verification_complete boolean coming from verification_request_completeness
model.
The completion time is computed as follows:
- Only considering verification requests that have been tagged as completed. From here, we have:
- If the verification request has, at least, one verification linked; the date will be the creation date
of the last verification created linked to that verification request.
To keep in mind: for some cases, the last verification can have updates after the creation, but these
generally happen with very low time differences with respect to the creation date. However, there are
some outliers - mostly linked to admin override - that we're not considering here, since these might
not necessarily be linked to the Guest completing the Guest Journey.
- If the verification request does not have any verification linked; we assume an automatic completion.
In this case, we use the time from which the verification request was created.
For some cases, it is possible that this logic still generates some completed times that are actually
before a user usage of the link. For these cases, we do an override and we apply the used_link_at_utc
as the completed time. To account for this cases, check the boolean column
is_completed_at_overriden_with_used_link_at.
In summary, the guest journey completion time provided here is an estimation.
Finally, this model only contains those request that have been completed, so keep it in mind when joining this
table.
columns:
- name: id_verification_request
data_type: bigint
description: id of the completed verification request. It's the unique key for this model.
tests:
- not_null
- unique
- name: estimated_completed_at_utc
data_type: timestamp
description: estimated timestamp of when the verification request was completed.
- name: estimated_completed_date_utc
data_type: date
description: estimated date from the timestamp of when the verification request was completed.
- name: is_completed_at_overriden_with_used_link_at
data_type: boolean
description: |
boolean indicating if the estimated dates have been overriden with the used link since
the initial computation was still considering an end date before a starting date.