Merged PR 2028: guest journey estimated completed date

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

models/intermediate/core/int_core__verification_request_completed_date.sql

@@ -0,0 +1,68 @@
+{{ config(materialized="table", unique_key="id_verification_request") }}
+
+with
+    stg_core__verification as (select * from {{ ref("stg_core__verification") }}),
+    stg_core__verification_request as (
+        select * from {{ ref("stg_core__verification_request") }}
+    ),
+    int_core__verification_request_completeness as (
+        select * from {{ ref("int_core__verification_request_completeness") }}
+    ),
+
+    verification_created_order as (
+        select
+            id_verification_request,
+            created_at_utc,
+            id_verification,
+            row_number() over (
+                partition by id_verification_request order by id_verification desc
+            ) as rn
+        from stg_core__verification
+    ),
+    verification_completed_at as (
+        select
+            vco.id_verification as id_verification_last_created,
+            scvr.id_verification_request,
+            icvrc.is_verification_request_complete,
+            icvrc.is_complete_only_from_previous_verification_requests,
+            case
+                when vco.id_verification is not null
+                then max(vco.created_at_utc)
+                when
+                    vco.id_verification is null
+                    and icvrc.is_complete_only_from_previous_verification_requests
+                then min(scvr.created_at_utc)
+                else null
+            end as verification_request_completed_at_utc
+        from stg_core__verification_request scvr
+        left join
+            int_core__verification_request_completeness icvrc
+            on scvr.id_verification_request = icvrc.id_verification_request
+        left join
+            verification_created_order vco
+            on scvr.id_verification_request = vco.id_verification_request
+            and vco.rn = 1
+        where icvrc.is_verification_request_complete = true
+        group by
+            vco.id_verification,
+            scvr.id_verification_request,
+            icvrc.is_verification_request_complete,
+            icvrc.is_complete_only_from_previous_verification_requests
+    ),
+    date_quality_fix as (
+        select
+            vca.id_verification_request,
+            greatest(vca.verification_request_completed_at_utc, scvr.link_used_at_utc) as estimated_completed_at_utc,
+            case when vca.verification_request_completed_at_utc < scvr.link_used_at_utc then True else False end as is_completed_at_overriden_with_used_link_at
+        from verification_completed_at vca
+        inner join stg_core__verification_request scvr
+        on vca.id_verification_request = scvr.id_verification_request
+    )
+select
+    id_verification_request,
+    estimated_completed_at_utc,
+    date(
+        estimated_completed_at_utc
+    ) as estimated_completed_date_utc,
+    is_completed_at_overriden_with_used_link_at
+from date_quality_fix 

models/intermediate/core/int_core__verification_requests.sql

@@ -6,6 +6,9 @@ with
     int_core__unified_user as (select * from {{ ref("int_core__unified_user") }}),
     int_core__verification_request_completeness as (
         select * from {{ ref("int_core__verification_request_completeness") }}
+    ),
+    int_core__verification_request_completed_date as (
+        select * from {{ ref("int_core__verification_request_completed_date") }}
     )
 select
     vr.id_verification_request,
@@ -28,8 +31,8 @@ select
     vr.guest_phone_number_2,
     guest.joined_at_utc as verification_start_at_utc,
     guest.joined_date_utc as verification_start_date_utc,
-    guest.verified_at_utc as verification_end_at_utc,
-    guest.verified_date_utc as verification_end_date_utc,
+    vrcd.estimated_completed_at_utc as verification_estimated_completed_at_utc,
+    vrcd.estimated_completed_date_utc as verification_estimated_completed_date_utc,
     vr.link_used_at_utc,
     vr.link_used_date_utc,
     vr.expire_at_utc,
@@ -54,3 +57,5 @@ left join int_core__unified_user guest on vr.id_user_guest = guest.id_user
 left join
     int_core__verification_request_completeness completeness
     on vr.id_verification_request = completeness.id_verification_request
+left join int_core__verification_request_completed_date vrcd
+on vr.id_verification_request = vrcd.id_verification_request

models/intermediate/core/schema.yaml

@@ -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.