Angulartics2 with Launch Provider



I am looking for additional guidance around using Angulartics2 framework with the Launch, by Adobe provider to implement data collection for Adobe Analytics. I am able to make it work but I am looking for best practices, suggested patterns, success stories, reusable components, etc. Any help from experts is greatly appreciated. Thank you.

Accepted Solutions (1)

Accepted Solutions (1)




Please take a look at the Data Layer Manager and AA Product String Builder extensions from Search Discovery.

The Data Layer Manager provides a standard way for applications to trigger Launch rules and to access the information in the data layer. It also cleanly handles the issues around asynchronous Launch load by de-queuing any events pushed prior to the Launch init.

I have an update coming very soon that will provide:

1) A new event type (Data Layer Push)

2) A new data element type (Context Aware Data Element) that ensures that application context is properly preserved when referencing a data layer value.

The interface from the application is pushing events onto a data layer array. For example, to trigger an event representing a "Product Added" (to cart), the following might be the application's action:

window.appEventData = window.appEventData || [];

This would trigger any rule that is configured to use the Data Layer Manager > Data Layer Push event with Event set to "Product Added".

Screen Shot 2019-01-31 at 8.11.56 AM.png

Launch can have as many rules as needed triggered off the event that was pushed (and using the payload data that was passed).  An example of an AA action sequence might have "AA: Clear Vars" > "AA: Set Vars" > "AA Product String: Set Vars" > "AA: Send Beacon".  The "AA: Set Vars" action would set the "prodView" event and any other simple "s" variables.

The "AA Product String: Set Vars" action would handle the Product String setup as below:

Screen Shot 2019-01-31 at 8.14.15 AM.png

I think that if the Angularitics system included a configurable way of filtering the slew of Angular lifecycle events to those that we care most about and a way to transform scope into just the desired attributes the solution would be really strong.

Answers (12)

Answers (12)




The way I'd approach this using Data Layer Manager is :

1) Create an AA PostTrackCallback that clears vars after each beacon.  (Forget about using the AA extension's Clear Vars action).

2) Have the angular app push an event when a view change is starting.  Use that event to trigger a rule that resets the data layer

3) Option1 -

     Trigger rules from each of the events that you care about which set AA variables but do not send a beacon.

     Trigger a rule from the last of these events that sets AA variables and ALSO uses the AA Send Beacon action.

Option 2-

     Trigger a rule only on the last of these events and utilize the __meta.computedState of that last event to set all appropriate AA values and then calls AA Send Beacon action.  Accessing __meta.computedState of an event is best done using the Data Layer Manager's "Context-Aware Data Element" DE type.

Option 3 -

     Create multiple rules, all triggered by the last event of the view change sequence.  Use rule order to sequence the execution of these rules.  Each rule could do part of the AA set variables work (this allows for conditional logic based on the info in the data layer).  The rule with the highest "rule order" would then be responsible for sending the beacon.

Anyway.  I think the first things to consider are :

1) It's fine for an event to be pushed to the data layer but not trigger a rule in Launch.  The payloads of these events may be accessed later via the comptedStates.

2) It's fine to have rules that are triggered by data layer pushes which set AA variables but do not send a beacon (as long as we know that later rule will be sending the beacon).

I hope that this gives some food for thought.   Also, if you'd like to buy me a ticket to Switzerland, I'd be happy to talk in person!






just a short feedback from current progress with angular: we decided not to use the angulartics extension.

instead, the devs implemented the "appEventData" DataLayer and are pushing data as described. what looked promising in the beginning (easy setup of the extension and mapping to data elements and rules) might end up with a lot of work for the devs. what we see are a lot of "multi pageviews": same pages have up to 6 calls to the data layer, some are only triggering once (on first view).

to sum it up:

- link tracking works great with custom solution

- pageviews look great, except they are called either once or multiple times. waiting for fixes.

I might come back to this thread and provide a solution as soon as we have the final code ...





we are in progress of implementing analytics on several Angular websites, trying to use the mentioned extension.

While the clickevent provided by the extension works as expected, the basic "onRouteChange" is the problem. Well, it's not a problem itself, you run into issues when you want more information about the page than just a basic route name. the reason is that at this point the app just doesn't know anything what is fetched later asynchroniously...

I really like the idea stewarts16448458​ described above. using a datalayer and having an extension that listen to the datalayer might work better.

as far as I remember the Angulartics2 extension itself provides sort of a datalayer, but might be wrong about that...

maybe jexnerW4D​ can jump in and provide some knowledge?




"The key here is to construct and attach the data layer before Angulartics fires pageTrack or eventTrack event."

This is one of the things that we set out to solve with the Data Layer Manager - By using a native JS Array at window scope, any application can push a data layer event regardless of whether Launch or the DLM has initialized. When DLM initializes, it inspects the array and processes any previously pushed events.   In the case of the Angulartics pageTrack and eventTrack events, if they simply pushed to the DLM array, then Launch could respond to the events triggered by the pushes.  

It's more of the GTM pattern - I wonder if you're already doing this when GTM/GA is your destination.



We implemented a data layer for Adobe Analytics without installing any additional extension for Launch. Angulartics2 can construct a payload with data layer but that is not required either. You can simply construct a data layer attached to DOM and let Launch translate all the variables into corresponding eVars and props. The key here is to construct and attach the data layer before Angulartics fires pageTrack or eventTrack event.




Hi stewarts16448458​  if you make it to Switzerland, would love to meet you!

regarding the issue: the problem is that there are 1:n components on the page every may or may not add data. and you do not know which one is the last and if more pushes are coming to the DL.

example: page loads a "dashboard" with several components. user can add/delete components as he wishes (not to mention that they might be re-arranged). from some of those components you want data, some are "just for decoration". that means the devs need to find a way to store all the relevant data and figure out when everything is loaded. I do not see any chance to detect the "last push" within Launch. what might be an option: if devs can detect (based on template), how many pushes should follow, that would allow me to install a "counter" and fire on "zero left".... however, waiting for the devs to come up with a solution

maybe I need to get into Angular and try to build an example app - at least I might understand where the problem is ...




the problem is not the dataLayer, it is how often "angular" pushes data. basically, "onroutechange" it is too early since a lot of information do not yet exists. and later are only the single components which mainly handle the content itselfs. that means "Angular" (or website) needs sort of "buffer" to pre-store information and send it out to dataLayer as soon as the last (relevant) component has finished/fetched data...




Hi All,

My feeling is that we're talking about two fundamentally different approaches here. Both have their merits and use cases.

I'd like to help you further, bobagrand​, but I have to admit that I haven't yet worked with decorated HTML at all. I guess the question is how to access all the data in the decorated HTML inside your Launch Rules and Actions.

Sounds to me like a blog article I need to write once I worked it out...



Thank you,

I will take a look at these extensions, although it is a bit off topic. Angulartics allows to abstract direct calls and triggering events by decorating action controls with parameters to be captured for analytics. Your example may be implemented with Angulartics by decorating any clickable object (<div> in this case) as follows:

<div angulartics2On="click"

         angularticsAction="Product Added"


         angularticsLabel="Product Added"


         [angularticsProperties]="{quantity: '1', sku: 'SK12345678', sellingPrice: '72.67'}">

      Click here to add product


Angulartics takes care of firing necessary calls invoking Launch rules behind the curtain. This syntax seems to reduce a risk of making programming mistakes and is easier to test. I am wondering if you or anyone at this forum can share their experience in using Angulartics. Thanks.