Clarify refresh timestamp behavior #958
Conversation
| The v3 Identity Map API provides a refresh timestamp (`r` field) in the response that indicates when each raw UID2 might refresh. Use this timestamp to determine when to regenerate raw UID2s for your stored data. It is guaranteed that it won't refresh before that time. | ||
| The v3 Identity Map API provides a refresh timestamp (`r` field) in the response that indicates when each raw UID2 might rotate. Use this timestamp to determine when to regenerate raw UID2s for your stored data. | ||
|
|
||
| It is guaranteed that the raw UID2 will not rotate before the refresh timestamp. After the refresh timestamp, when remapping the DII, a new refresh timestamp will be returned but the raw UID2 may not rotate. This is by design to encourage more frequent checks of the opt-out status of the underlying DII. |
There was a problem hiding this comment.
-
again instead of rotate I recommend change or refresh or some other wording that just says it's a new value.
-
will be returned > is returned
-
may not > might not
(same comments for all instances of this wording)
There was a problem hiding this comment.
Updated the copy to: "The raw UID2 is guaranteed not to change before the refresh timestamp. After the refresh timestamp, remapping the DII returns a new refresh timestamp, but the raw UID2 might or might not change. It is possible for the raw UID2 to remain unchanged for multiple refresh intervals."
genwhittTTD
left a comment
genwhittTTD
left a comment
There was a problem hiding this comment.
Left a few copy comments.
genwhittTTD
left a comment
genwhittTTD
left a comment
There was a problem hiding this comment.
Updated per thread. Approving, but LMK if you need anything else. Thx.
No description provided.