Resolution Reference

This section provides technical specifications and reference information for flag resolution and application.

​

Apply a Flag

​

Timestamps

Each apply requires two timestamps using the client’s local clock:

• appliedTime: When the flag value was actually used in the application
• sentTime: When the client reports the apply to Confidence

These two timestamps allow accurate tracking without requiring synchronized clocks. The difference helps account for:

• Network latency
• Batching delays
• Offline operation

​

Batch Requests

It’s recommended to batch apply operations:

• Reduces network overhead
• Saves battery life on mobile devices
• More efficient for the service

Wait for opportune moments (like when doing other network requests) to report applies.

​

Mobile and Offline Scenarios

For mobile apps and offline scenarios:

1. Queue applies locally while offline
2. Send all queued applies when network is available
3. Piggyback applies on other API calls
4. Preserve the original appliedTime even if sent later

​

Handle Errors

Apply operations should be fire-and-forget:

• Log errors for debugging but don’t block application flow
• Don’t retry immediately to avoid overwhelming the service
• Consider queuing for later retry
• Applying is not critical to UX—the flag has already been resolved

​

Monitoring

Track apply metrics to ensure data quality:

• Apply rate: How often flags are being applied
• Apply delay: Time between appliedTime and sentTime
• Apply failures: How many applies are failing
• Missing applies: Flags that were resolved but never applied

​

Best Practices

• Apply only when the flag value is actually used
• Batch applies together when possible
• Use accurate timestamps (set appliedTime when flag is actually used)
• Handle failures gracefully without breaking application flow
• Queue applies when offline and send when connected
• Monitor apply rates to ensure experiment data is complete