Patch'y Updates for IGs Previously Joined on Same Joining Origin, i.e. interest_groups.joining_origin=origin of current TLD about turtledove

[dmdabbs]

...the DSP might use the pattern of "drop the IG, let it trigger the update with the new tech that lets the updates trigger a lot, and then just let the server provide the configurations".

Is tech that lets the updates trigger a lot referring to updateIfOlderThanMs?

[thegreatfatzby]

Right.

[dmdabbs]

DSPs whose "inserts" start with an empty, eligible-but-not-biddable IG will have to wait until after the first post-auction update to use updateIfOlderThanMs. In the sunny, scaled PAAPI future that wait might not be very long. But, yeah, 'overwriting' the twenty-day-mature IG with the empty "insert" might mean waiting up to 24 hours for that next, restorative update.

1. Extend the TTL of the IG identified by (owner, name), without wiping out any other fields.

Perhaps an approach to # 1 is to, say, include updateIfOlderThanMs in the "insert." If it is present, and the IG already exists, then the other IG attributes are ignored and you get an update, not just leaving the IG undisturbed.

In any event, this new mechanism would still increment the internal join count and recency, yes?

2. Do a PATCH'y update of fields on an IG identified by (owner, name), i.e. not wiping out any other fields.

If the DSP is using empty "inserts" would it have any patchable values?

[davideanastasia]

My understanding is that updateIfOlderThanMs will trigger a fetch from the update URL, but the update URL cannot extend the TTL of the interest groups, hence 20 days into the life of the interest group, despite the refresh of its content, the IG will only live further 10 days. Am I understanding this incorrectly?

[dmdabbs]

Am I understanding this incorrectly?

You are not, Davide. My response was poorly worded. Implicit was an assumption that the new API surface/flag that will enable @thegreatfatzby's #1 will be updating the lifetimeMs expiry. I was wondering whether we could also get a shot at triggering the updateURL.

[thegreatfatzby]

That would seem a good option...I did put this on the list for coming Wednesday, maybe we'll get to it.

[dmdabbs]

Hmm. I forgot updateAdInterestGroups() exists (prolly why I asked for it to be added to the explainer). Paul J's PR today brought it to mind.

[thegreatfatzby]

That's not permanent, at least as of yet, right?

[dmdabbs]

That's not permanent, at least as of yet, right?

I've not seen any references that it is temporary. It is in the spec.

[thegreatfatzby]

Interesting, I was referring to this but maybe I've overinterpreted that as being temporary.

[dmdabbs]

If it were temporary they probably would not have patched the explainer or would have noted it.

[JensenPaul]

I suspect there is some possible improvement we could make to address this issue. One concern is how we avoid IGs containing information from multiple sites. For example if you join an IG on site A, then join (and overwrite) the IG on site B, then go back to site A and try to do a partial IG update, e.g. try to extend the IG's TTL. We discussed a similar risk in this comment and the group-by-origin optimization. The outcome in those two previous instances was to delete the IG (and in the case of group-by-origin, all other group-by-origin IGs joined on that site) if it was accessed on two different sites. Do you think this is a reasonable outcome here?