Overview


The checkin backstop feature is a feature that was created for Ipsos to solve the problem of shoppers on the BP project taking their sweet time to submit shop reports after the shop has been completed.  BP prioritizes getting their data quickly so that they can address any issues.  We have a "hot alert" action question set up on the BP dispenser series survey that notifies Verb (third party service) that in turn notifies BP if one or more dispensers has a critical failure, or two or more dispensers have non-critical failures.  The hot alerts aren't so hot if the shopper doesn't submit the report for a day or two after they visit the location.  At the same time, Ipsos wants to have long incomplete_evaluation_durations on their batches so that a shopper can plan ahead/set up a route, but once the shopper does the shop, they want the report in a timely fashion.


The solution is checkin backstop (https://app.clickup.com/t/2291831/86e2bfqta), a run setting that resets the evaluation expires time at the first checkin event (checkedin_backstop_duration, in UI "No reduced time to submit after check-in" prior to setting and "Once a shopper "checks in" the shop, they will have at most x minutes to submit the shop." once the checkin backstop value is set).  


How it works: general case


In the case of a batch with no batch backstop (backstop_duration), the behavior is as in the following example:

  • Batch has an incomplete_evaluation_duration of 432000 seconds (5 days) and a checkin_backstop_duration of 43200 (12 hours)
  • Shopper clicks on shop preview at 2026-07-21 08:00:00, creating an evaluation with expires 2026-07-21 08:03:00 (three-minute ticketmaster timeout)
  • Shopper claims shop at 2026-07-21 08:01:00.  Evaluation expires is updated to claim time plus incomplete_evaluation_duration (2026-07-26 08:01:00)
  • Shopper checks in at  2026-07-23 17:15:00.  Evaluation expires is updated to checkin time plus checkin_backstop_duration (2026-07-24 05:15:00), giving the shopper 12 hours to submit the report


How it works: batch backstop


A batch backstop limits the expires time of any evaluation in the batch to at most the batch end date (period_end) plus the batch backstop (backstop_duration).  If a shop is claimed on a batch with a batch backstop, the expires time is set to claim time plus incomplete_evaluation_duration (as in the general case above) or to period_end plus backstop_duration, whichever is sooner.  Adding a checkin backstop will not cause the expires time to extend beyond period_end plus backstop_duration.  For example:


  • Batch has an incomplete_evaluation_duration of 432000 seconds (5 days), a checkin_backstop_duration of 43200 (12 hours), a period_end of 2026-07-31 23:59:00 and a backstop_duration of 28800 (8 hours)
  • Shopper clicks on shop preview at 2026-07-30 08:00:00, creating an evaluation with expires 2026-07-30 08:03:00 (three-minute ticketmaster timeout)
  • Shopper claims shop at 2026-07-30 08:01:00.  Evaluation expires is updated to period_end plus backstop_duration (2026-08-01 07:59:00) because the claim time plus incomplete_evaluation_duration would put it beyond the backstop time.  
  • The expires time may be updated, depending on when the shopper checks in:
    • If the shopper checks in at 2026-07-30 16:00:00, expires is updated to 2026-07-31 04:00:00 (12 hours from claim time as in the general case above)
    • If the shopper checks in at 2026-07-31 23:00:00, the expires is not updated (i.e., the shopper had 9 hours to submit the report: checking in will not update it to give them 12 hours instead)


Other considerations


As described in the batch backstop case above, a shopper cannot use the checkin backstop to game the system and override the batch backstop to gain additional time.  Likewise, if the shopper checks in again, this will not reset the 12-hour clock.