A note with this method:As a pre-req, you will need to make sure that the s object is defined globally in your Analytics extension.Then, this code must be placed in an action before sending the beacon or in a rule must fire before the one used to track your event, event10. If the intention is to use this after all beacons, then it should go in a separate rule that fires before any other rules that send a beacon. If placed in custom code before using the AA extension, you could run into a race co...

Hi @tim_funk , part of the question was how to retain some of the variables after the beacon has fired. This would clear out those that are meant to persist.

Hi @DebbyNPL ,It does sound like clear vars is normally the right way to go, but you have several options if you want the remaining variables to persist:Explicitly unset the event in custom code. E.g. Using yuhuisg's code to unset all events.Set the event/fire beacon in custom code using variable overrides. This is personally my favorite technique to send data only relevant to click tracking that I don't want persisting after a click--event10 in your case.You could also make sure to set event10 ...

Just as a note here, it is best to stick with the debug logging which doesn't require updating code or accidentally leaving in console logging.Instead of using console.log(), try to stick with _satellite.logger.log() These debugging entries can sometimes stay in your code to help you the next time something breaks.

Hi @C_Evans , Three Options (all require the Analytics extension to include the AppMeasurement code):Option 1: Use custom code within an Analytics set variable action. This will always allow access to an object with the s namespace. The caveat there is, if the s object isn't set globally, you may have to send the beacons within the same rule as the custom code since you are referencing a local s object, but you could test to see if these values persist through other rules. Option 2: As an altern...