Skip to main content

I have some questions about Reverse ETL functionality and was wondering if additional documentation or guides exist on this topic.
 

Scenario:

A relative date query identifies users who requested quotes within the last 5 days with 10-day lead times before their arrival and do not have a confirmed booking. These users are flagged as TRUE via a trait (e.g., early_quote_user). From an initial group of 10 tagged users:

  • 2 later convert to confirmed bookings (no longer meeting criteria).

  • 3 new qualifying users are added as TRUE the next day

Key Questions:

  1. Should the logic to mark converted users as FALSE be implemented directly in the SQL query?

  2. If not explicitly handled, will those users' traits remain TRUE indefinitely?

  3. Are there alternative methods to automatically transition users from TRUE to FALSE when they no longer meet criteria?

Hey David.

To keep things accurate, the key thing is that your SQL logic should explicitly handle both the case where a user qualifies (set to TRUE) and when they no longer qualify (set to FALSE). Otherwise, if someone drops out of the results (like they end up booking), but we don’t include them in the output with an updated value, Segment will just leave their trait as TRUE indefinitely.

So yep, if 2 users convert and no longer meet the criteria, they’ll still show up as early_quote_user = TRUE unless your query actively resets them to FALSE.

There are a couple of ways to manage this:

  1. Modify your SQL query to return both TRUE and FALSE values explicitly based on your logic.

  2. Use a Full Sync (vs Incremental) in the Reverse ETL settings, which ensures the entire user set is updated regularly—not just recent changes.

  3. If you're using Twilio Engage, you could also handle this with computed traits, which let you build more dynamic trait logic based on event behavior and time windows.

Reply


Terms & Conditions