Is there a way to also include session metrics in ...
# ask-questions
n
Is there a way to also include session metrics in an experiment? I have a sessionID differentiating the data.
f
Hi Kasper - how do you want to use the session data? as a randomization unit, for session metrics?
n
Hi Graham. I want to have metrics where the user needs to have seen the experiement in the same session as the metric event is counting
f
Hi @nice-shampoo-1738 I think it matters how you setup your events in for example Google Analytics. So the tracking callback event which sets the experiment and variation information on the datalayer can be picked up with GTM tags by GA4. Then in GA4 you set the event scope: user/sesssion/hit. Normally you would setup the GB tracking callback event as user scope. Then this info stays within the user and all following sessions from that user. Then you select which metrics you want to use which ever they are in for example GA4. Then in growthbook you can create the metrics based on your GA4 metrics. In order to help you further I think it would be good if you can share more about your data integration setup with Growthbook.
n
I have data in Growthbook from mParticle via BigQuery
f
Ok and the trackingcall back from growthbook is that also going to mParticle and if so how? You need to have this data send to mParticle so that you then can create metrics in growthbook that count number of visitors, sessions or pageview etc. I would recommend to scope this tracking call back event by default called exeperiment-viewed on a user level.
@nice-shampoo-1738 Yeah I’ve checked some documentation from mParticle. And you should use the info from the tracking callback to create a custom event for mParticle: https://docs.mparticle.com/developers/quickstart/web/track-events/ In this event you can then put i.e.: Eventname: viewed-experiment Key: AB-Test-001 VariationID: 0 Here is an example we use:
Once you have tracking callback event working you then get experiment data in mParticle and after that in BQ. As an assigning attribute (attribute that is used to devide visitors between your experiment variations) I would use the userID attribute which you can configure for anon user Id or logedin userId from mParticle. Then GB will count the visitors for you in your experiments. Then you can add metrics in GB like number of sessions or pageviews etc. I would not use sessionId as an assigning attribute as it’s know to skew data sets. https://towardsdatascience.com/the-second-ghost-of-experimentation-the-fallacy-of-session-based-metrics-fb65006d30ff
n
Thank you @fresh-stone-24633 That is exactly the tracking setup we have. Sending the experiment viewed events to mparticle. Sending that to BQ. Pulling metrics in from BQ to Growthbook. But What I cannot wrap my head around is how to have not only set the metrics as user conversions (the user having at least one conversion in the conversion window), but also as session conversions (having the conversion happening in the session where they where included in the test)
f
Hi @nice-shampoo-1738 thanks for confirming your setup 🙂 that really helps. So my approach would be to create a custom metric in mParticle Conversion within 1 session. This info will then go to BQ and from their create a metric in GB “Conversion within 1 session” that pulls the data from that newly created custom metric in mParticle. What happens is that you then get users from your experiment that converted in the same session as they got into the experiment. Let me know what you think.
n
@fresh-stone-24633 thank you for responding again. So the only way would be to introduce a new tracking point in the original tracking? No SQL making possible?
f
@nice-shampoo-1738 Yeah I’m sure you can also create that by creating a SQL however I can’t help you with that. I also would recommend to create a custom metric in mParticle because from a query cost perspective it would be a lot cheaper as you are then just pulling data in stead reworking that data into something new which will make the query take longer which impacts the query costs. Creating a custom metric shouldn’t be a big deal I suspect. Probaly easier than fixing it with SQL.