Hi everyone! We’re experiencing an issue where, for A/B tests that occur very early in our app, the activation event (e.g., viewing the splash screen) happens milliseconds before the user is assigned to the experiment via the

trackingCallback

. This timing causes GrowthBook to filter out these users from the experiment analysis because the activation event precedes the assignment. Is there a recommended way to handle this scenario so that users are accurately included in the experiment data, even if the activation event occurs before assignment? Any guidance on adjusting the timing or configuring the SDK to assign users earlier would be greatly appreciated. Thank you for your assistance!

a hack -- but can you just add a second or two to your activation metric SQL so that the timestamp gets shifted? it won't strictly guarantee the order, but unless you are looking at very short sequences that may be the easiest adjustment

Yes, that is a good hack. Or using the "Advanced Setting" of Metric Delay and setting a negative metric delay, which will operate similarly.

@helpful-application-7107 Hey I’m a colleague auf Paul and we tried this, but hit a limitation which doesn’t make much sense to us: The negative metric delay needs to be <= -0.125 to be recognised in the generated query. If we set value closer to 0 it is simply ignored (eg. -0.05). And even with -0.125 the generated query uses 8min instead of the expected 7.5min 🤔

...
 __experimentUnits AS (
      -- One row per user
      SELECT
        e.userid AS userid
        , (CASE WHEN count(distinct e.variation) > 1 THEN '__multiple__' ELSE max(e.variation) END) AS variation
        , MIN(e.timestamp) AS first_exposure_timestamp
        
        
        , MIN((CASE WHEN a.timestamp >= e.timestamp - INTERVAL '8' minute
      AND a.timestamp <= from_iso8601_timestamp('2024-12-16T12:25:53.665Z') THEN a.timestamp ELSE NULL END)) AS first_activation_timestamp
            
      FROM
        __experimentExposures e
        
        
        LEFT JOIN __activationMetric a ON (a.userid = e.userid)
      
      GROUP BY
        e.userid
    )

Hi, I think we do some rounding under the hood. This isn't totally unexpected to me, but I'll take a look.

Great, thank you Luke!