Does userID take too long to initialize by default?

[dgirardi]

Type of issue

Question / feature request

Description

#8201 introduced getUserIdsAsync(), which gives publishers a way to wait for all userIDs to complete initialization.

The time it takes for userID calls to complete is controlled through syncDelay and/or auctionDelay configuration. By default, if neither is specified, userID modules will not start making their network calls until the first auction has completed.

This results in getUserIdsAsync() taking a surprisingly long time, as the discussion in #5447 shows. It can be made quicker by setting auctionDelay: 1 (or greater), which does not seem very intuitive.

Should we change the default behavior, or give a more explicit configuration option to start userID init early?

[patmmccann]

tagging #8295 as related

[patmmccann]

@jdwieland8282 can you provide any feedback on this? We're interested your take, should auctiondelay 0 be faster than 1

[premesh-freestar]

Config/Setup around this is certainly not straight forward. I think the config option would be ideal (with perhaps some cleanup/refactor of what is there now to address the confusion).
Understand this would imply larger changes but feels like we should be able to provide an timeout to get userIds similar to how we handle getting consent data ?

Would a timeout and target options work where target would be PRE-AUCTION POST-AUCTION or MANUAL (to allow only manual triggers for custom logic)

[patmmccann]

The proposed requirement for the fix is that:

auctionDelay: 1 should delay longer than auctionDelay: 0; and hence, that if someone explicitly sets 0, it will fire one ms before auctionDelay 1. If the value is not explicitly set, the default should be the existing behavior, initiating after the end of the first auction.

[jdwieland8282]

#8311 (comment) yes intuitively it makes sense that the lower the integer the shorter amount of time need elapse before triggering the function.

[patmmccann]

Tagging this as 7 to make sure we include in release notes, people should be well aware of behavior changes on this. Soliciting requirements feedback.

[dgirardi]

It makes sense that auctionDelay: 0 should yield userIds faster than auctionDelay: 1.

But does it make sense that if your goal is to get userIDs sooner, you need to explicitly set auctionDelay: 0? Or that if you are interested in running the auction ASAP, you should not explicitly say auctionDelay: 0 (so as to avoid additional activity competing for the connection pool)?

Additionally, it turned out that in the original issue the OP was never interested in waiting for userID calls to complete, they just wanted to know the right time to get the cached IDs - now I'm wondering if changing the behavior of an auctionDelay: 0 would help anyone.

[EskelCz]

@dgirardi I still feel it would be beneficial to make the getUserIdsAsync work better. We don't particularly need it anymore though, that's correct.

[patmmccann]

It seems like a new configuration option is preferred to changing the behavior of auction delay zero; still assessing publisher demand.

[patmmccann]

@dgirardi dumb q here: if a pub also has enableOverride set to true, does triggerUsersyncs fire the user module syncs or are those governed by the other params?

[dgirardi]

enableOverride has no effect on userId, only on user syncs as defined by bid adapters.

[patmmccann]

500 is a reasonable default; we can change it and move on. Arrived at by extensive yield testing.