This message was deleted.

hrmm, you dont need to use the growthBook SDK to do that - you could just fire the event yourself if you have already assigned them

We could fire an "experiment viewed" tracking event manually, but if the visitor refreshes the page or visits it again later, we of course want to give the same variation. And that is only possible if this variation is linked to the attribute.id

If I understand correctly, if the users do not accept cookies, we cannot guarantee the same variation if they refresh the page. For users who do eventually accept the cookie, but initially request without one, what you can do is generate an ID in the middleware (at the same step as assigning the variation). Then send it to the client, and once they accept cookies, store that ID for continued use. Does that make sense?

We know the variation based on the URL. For example, a user navigates to /somePage and we redirect that in the middleware to /pregenerated/somePage/variant=1/ Then we know from the URL that the user sees variant 1. I understand the idea of providing an ID from the middleware, but the page is generated during the build and the only way I know to provide something is with a cookie, and I don't want that. We had some other issues with the static pages, so we decided to refactor it and we are now going to use streaming SSR.

Ok, that makes sense. Thank you sharing