I am trying to track carousel banner impressions with events via GTM for Universal Analytics. I have seen many solutions covering _gaq.push but really need dataLayer.push solutions because we're migrating all hard-coded tags to GTM..
A single banner works, as I've used gtm.load rule to pick up the dataLayer.push, but when there are multiple banners, this solution doesn't work.
Any ideas/links that could help?
The _gaq.push method fires GA Events directly from the carousel. When you convert to GTM, you fire these events indirectly using GTM.
The first step is to convert the _gaq.push calls to fire custom GTM events using dataLayer.push(). In addition to firing the GTM Event, you'll have to push some sort of carousel item identifier into the dataLayer. Usually this is the URL of the image or a caption. Likely the _gaq.push call was also sending this identifier.
Once you have this working, create a rule that looks for that GTM event, and then create a GA Event tag that fires when the rule is true. You'll also want to create a GTM macro that pulls the identifier from the dataLayer. Use the macro in your GA Event tag to pass the identifier to GA.
See the Using the Data Layer with HTML Event Handlers section of this page https://developers.google.com/tag-manager/devguide for information on firing custom GTM events.
Related
I'm trying to wrap my head around GTM Tags and how they work in GA4.
For example I have this GTM tag that fires when a button is clicked. This is working and I can see the event fire in the GA4 debug view.
If I did nothing else would I be able to see the event count of map_grid_view without registering a custom dimension? (I know the event parameters would not show)
If i registered click_text and page_path as custom dimensions then re-used those event parameters in other events I created would that data pull automatically into GA4 once i published my GTM container? (Is this approach considered best practice?)
Yes. You don't need to register the event name
Yes. It's a best practice if you can re-use them. Since free version of GA4 only allow us to register 50 custom dimensions and metrics. If the tracking strategy go complicated in the future. The quota is not enough then.
According to the XForms specification most events are said to "bubble".
As per the DOM Level 2 Event Specification an event that "bubbles" means that the handlers for this event associated with ancestor elements of the event dispatch target will also receive this event.
For an event to be specified as "bubbles" it means the xf:dispatch action cannot modify the bubble behavior to limit it to the target.
I don't understand what the benefit is of so many xforms events to bubble. For example, xforms-select and xforms-deselect. They apply to xf:item (of xf:select*) and xf:case (of xf:switch, i.e., used in a form with tabs).
Let's say I have an xf:case with an xforms-select handler that will cause a refresh on an expensive rendering widget, just when the tab is actually selected rather than every time the model is updated. Now I also have an xf:select in that same tab. Now whenever the user selects another item in that selection, the xf:case would receive the xforms-select at the bubble phase, doing the costly update operation every time.
This doesn't seem to make sense.
In fact xforms-node-attached has it right: we really want to be specific as to which form element gets the node attached. But apart from that, most events are said to bubble.
I could conform myself better with this issue if I understood the reason for this. Otherwise I am tempted to change my XForms engine to change the definition of xforms-select and xforms-deselect not to bubble.
This is to allow what is known as event delegation:
"Event delegation refers to the process of using event propagation (bubbling) to handle events at a higher level in the DOM than the element on which the event originated. It allows us to attach a single event listener for elements that exist now or in the future." (from an older version of this jQuery doc page)
In general, this is a good thing:
You use less event listeners.
A listener can listen on multiple targets.
You don't need to remove/add listeners as DOM elements are added/removed.
It seems that, in the HTML world, things have moved towards letting everything bubble. For example, the old focus event didn't bubble, and the newer focusin event bubbles.
If you have an event handler which gets activated by events dispatched to multiple targets, in some cases you need the ability to discriminate. This is where event context information is useful. Libraries like jQuery also allow you to associate an event handler filtered by CSS selector, which is neat.
Now in the case of xforms-select specifically, your issue is that you cannot discriminate between this event dispatched to an xf:case vs. an xf:select. This might mean XForms shouldn't have a single event for these two scenarios, or it should have enough event context information to discriminate between the two. I don't think that this is making a case for not letting the event bubble.
I'm in the process of upgrading a couple of sites to Universal Analytics and need some help setting up goals for conversion tracking...
I am now using auto event tracking (click listener) to see where users are clicking on the sites' forms, but I'm not sure how I can create goals for form submissions as the URL does not change. (Previously I was sending virtual pageviews when the submit button was clicked, but I don't think it's possible to do this in Universal Analytics?)
I know by using the click listener I can still see how many times the submit button of the form is clicked, but I need to set this up as a goal so I can monitor the cost per conversion of my AdWords campaigns.
Any help appreciated!
loop, if you are using GTM, you can simply use Form Submit Listener:
This listener then could fire an event tracking, which will serve as the condition for any conversion goals you might need. Just keep in mind when setting the conditions for goals, ALL of the Event-related dimensions (category, action, label) need to match, even though you can use only one (for example category = form submitted) as well.
I have read all the official documentation of jQuery 1.7.2, but I cannot find any detail about the 'beforechange' event (or something like that) which help me control some rules before allowing the element to change its value. Is there any plugins provide this handler?
Thank you so much!
The jQuery api doesnot provide the 'beforechange' event but instead provide great flexibility to write our own custom events. We can define our own custom events and can be triggered when the events is fired.
For example for input elements we can have onkeydown or onkeypress events and when fired we can trigger our custom events to control some rules.
The following link provides information for creating custom events. Its very simple and flexible.
http://scriptble.com/2009/05/custom-events-with-jquery
What makes more sense (or is proper according to google)? Registering an event or a virtual pageview with Google Analytics when tracking navigation through a webpage with heavy use of ajax?
I had been using events to track this kind of thing, but I find myself kind of emulating the pageview mechanism by tracking the clicks through events like the following:
_gaq.push(['_trackEvent', 'signup', 'clicked', 'header']);
should I instead be creating virtual pageviews when visitors click on links that call AJAX and bring up dynamic content?
_gaq.push(['_trackPageview', '/signup/form']);
If this is a new content that user navigates to, then you should be using virtual pageviews.
If you use events for all navigation then some metrics will be unreliable like pages/visit, avgTimeOnPage, avgTimeOnSite, pageDepth. If you use pageviews for navigation these metrics will be closer to the truth.
Since not so long ago, you couldn't set up goals for events, which made virtual pageviews the way to go. These days, you can set up event goals, so the question is certainly valid.
What you can do with virtual pageviews (and not with events) is to visualize a funnel. If you want to follow the path of your visitors, I'd recommend a virtual pageview.
If you're using events, you can only find out that some time during the visit, the visitor opened the form. With virtual pageviews you can see in what preceeded the form, what lead the visitor to it.
I would go with the event tracking for more information about the event. Showing an in-page form that doesn't change the content is more of an event, but it's not really down to that, but rather how you need to report it.
Using pageviews for dynamic events within page would inflate the actual pageview numbers and since you can use events as goals in the new UI, there is no reason to track them as pageviews anymore.