Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does userID take too long to initialize by default? #8311

Open
dgirardi opened this issue Apr 21, 2022 · 12 comments
Open

Does userID take too long to initialize by default? #8311

dgirardi opened this issue Apr 21, 2022 · 12 comments

Comments

@dgirardi
Copy link
Collaborator

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
Copy link
Collaborator

tagging #8295 as related

@patmmccann
Copy link
Collaborator

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

@premesh-freestar
Copy link

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
Copy link
Collaborator

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
Copy link
Member

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

@patmmccann
Copy link
Collaborator

patmmccann commented May 23, 2022

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
Copy link
Collaborator Author

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
Copy link
Contributor

EskelCz commented May 23, 2022

@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
Copy link
Collaborator

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

@patmmccann
Copy link
Collaborator

@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
Copy link
Collaborator Author

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

@patmmccann
Copy link
Collaborator

patmmccann commented Jul 28, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Ready for Dev
Development

No branches or pull requests

5 participants