How to get multiple events/rules to fire as part of same beacon by using Adobe Launch?

[jgibbons6031]

Hi community,

I am working on a site where the admins are cognizant of the number of beacons being sent and want, where feasible, to limit bloat in that regard. As such, I am looking for a solution in Adobe Launch wherein we can get multiple events to fire as part of the same beacon, when applicable.

Note: event#s below are just examples for simplicity sake.

For instance, if someone clicks into a form field and changes the value, right now it is firing 2 (if not 3 beacons): one for the Link Click (event1) into the field, one for the Form Field Change (event2 - "on change"), and then one for when they click to the next form field (event1 again). I would love to couple the event2 to one of those event1s, if possible, so that they were part of the same beacon. 

If that example is not feasible, other examples would be:

1. Coupling a Video Start (event3) with the corresponding link click (event1) that triggered said media start
2. Coupling a Form Load (event4) with a Page Load (event5), when that form loads as just part of the page (no addt. action required)
3. Coupling a Click Event (event1) on the "Submit" button with the Form Submit (event6), when the form successfully submits (no errors)

Would welcome any and all advise on how to couple events under the same beacon/tag, as I have seen on other sites (where I do not have Adobe Launch permissions) this being achievable in some fashion.

Thank you!!

[yuhuisg]

When considering what data points to track together, keep in mind the impact on reports too. Particularly with dimension breakdowns, because breakdowns can only be done when data are together in the same hits (keeping in mind post-processed data from eVars that have non-Hit expirations).

With that said...

Usually, I will have to consider the business questions. For example, with your form tracking, it sounds like you have 3 beacons because you want to know:

• Are users getting to the form fields that we want them to get to? Answered by knowing which fields they had clicked.
• Which form fields might be relevant to users? Answered by knowing which fields they had changed.
• How successful are we in getting users to submit the form? Answered by knowing whether they click the "Submit" button.

Of those, the one that I would eliminate quickly is click tracking of the "Submit" button, because this can be implied by the page views of the form submission confirmation page, assuming that one is shown after submitting the form successfully.

For the other two (clicking into the field, and field change behaviour), it would depend on whether you are really using that data to answer questions now. In my experience, these are valid business questions, and good to know if you're actively running A/B tests on your forms. But if no one is really looking at that data, then one or both could be candidates for elimination. Or it might turn out that knowing if users clicked into the fields is not as essential as knowing if they had changed the field's value, so the first one could be eliminated.

As you can see, there are these rounds of thinking that have to be considered when figuring out what needs to be tracked. There really is no straight answer.

... Finally, when you are tracking user actions that are really one-and-the-same, e.g. like the 3 that you mentioned:

1. Coupling a Video Start (event3) with the corresponding link click (event1) that triggered said media start
2. Coupling a Form Load (event4) with a Page Load (event5), when that form loads as just part of the page (no addt. action required)
3. Coupling a Click Event (event1) on the "Submit" button with the Form Submit (event6), when the form successfully submits (no errors)

Then yes, those are definitely candidates for tracking reduction, i.e. you really want to track user behaviours, and not necessarily the technical workings of the page or its components.

[leocwlau · Accepted solution]

As @yuhuisg mentioned that you need to be aware of the impact on the reporting and the correctness as well.

A single event should be a tracking of a single user interaction or web behavior presented to users. Your three examples are not singular from my point of view.

Taking user interaction as an example, without considering tracking consolidation, we may have separated tracking on:

• click on any <a> to download file
• click on any <button>

In case there is a file download within a button, <button><a href="abc.pdf"></button>, there will be two tracking fired upon one single user interaction. This is a case where we can consolidate hits and maintain correct reporting.

I had a sharing on this years back on an Adobe Skill Exchange and an article on how to do that.

---

A newer approach in my mind is adopting an event-driven data layer, where we sequence different data pushed according to the tracking context (such as button clicks or file downloads) without the event first, then a data layer push with the event upon the common user interaction, a click.

[jgibbons6031]

Thank you both!!! @leocwlau the article you linked to was especially useful and helped me get to the solve I needed, much appreciated.