SETUP:
Having a few different information sites/domains about my products and one single site/domain shop-site where you the purchase, checkout and so on happens, I'm having troubles to find a proper solution for a comprehensive tracking of all the pages including the conversion tracking.
IDEAL:
What I want is to get reports seperated for each site (shop-site as well as information-sites), but add some conversion tracking. Ideal would be to be able to track a conversion when the user gets to the checkout process, so that I can see it in the statistics of the shop-site as well as on the site that referred to this sale/conversion and maybe even a funnel visualisation for the whole action.
WHAT I ALREADY GOT:
I already set up statistics for each site/domain. I do have set events for a referal to the shop-site as well as an event when the user checks out.
WHAT I TRIED:
I set up cross domain tracking for one of my information-sites and the shop-site, so now the events show up in that single property.
Unfortunately thats not the statistic I intend to get, as the whole data got consolidated from those 2 properties. Also it made the tracking goal/conversion only accessible for that single property, while I can't distinguish between a conversion made originally from this site or one of the others.
Is it possible to achieve what I actually intend to do or what's the proper way to track such a setup??
You can either use an additional tracker (so you have one UA id that goes in your "normal" domain, one that goes in your shpooing site and one that is placed on both sites) - you'd still have both pages tracked in separate properties, but you'd have one rollup property that tracks all your sites. This might however unwanted complexity if you use event tracking etc (since you'd have to see to it that events are always pushed to the correct tracker).
An easier solutions is via views/profiles - use the same UA id for both sites; create views based on domain name (filter in the admin section) to track each site separately; for the common data view that display data from both sites create a filter that includes the hostname in the reports so you can tell both sites apart in the report.
Related
I have a situation and I am not sure how to solve it.
I am using a script in Google Tag Manager to define where marketing sources are coming from (i.e. organic search, organic social, paid search, referral, direct traffic, etc.).
I am taking the data from that script and storing it in a 1st party cookie & first party cookie variable.
However, I need the data from the cookie to populate in the URL query string, similar to how utms populate in a query string when someone clicks a Google Ad.
For example, when someone clicks on a Google ad, they arrive on the landing page and the URL looks something like this www.examplesite.com/?utm_source=Google&utm_medium=ppc&utm_campaign=example
I need similar functionality to that. So in my example, if someone came from an organic search result, I would want it to look like this:
www.examplesite.com/?Source=Organic&SourceDetail=Google.
Is this even possible to do on the initial page?
Yes, there are a few ways of going around it. I will only highlight the most elegant option, but first, you don't need to touch your query string. You can override the string that is being sent to GA with GTM. It's a lot more elegant than tinkering with the user-exposed front-end. Here is how:
That's how you override your location dimension (dl) in your pageview tag.
Now the only thing that remains is to make that custom javascript variable returning a string that would be just your current url with the proper utm-params appended to it.
This is a very clean and non-intrusive implementation. You can also do it on a GA settings variable level, which may be even a better solution, depending on your situation.
Also, you can override your source/medium using an event, rather than a pageview, but be careful with events. A change of source/medium will force GA to generate a brand new session for this user. That is done to be able to build different attribution models on the same dataset.
It seems that Custom Dimensions are the new way to send custom data from a website to GA. I'm new to GA but my manager has used GA in the past and I'm guessing this was before the CD structure existed in GA. Do you know when the CD structure was introduced in GA?
He has sent custom data to GA in the past using events. This seems like a viable way of sending data and another manager at my company had referred to this approach last week so it seems like maybe this was a standard approach before GA introduced CD's. So given the following request:
var myRequest =
{
UserID:1234,
SelectedReportType:1,
};
What are the tradeoffs between sending this request data to GA as a CD like this:
ga('set', 'dimension1', JSON.stringify(myRequest));
ga('send', 'pageview');
Vs sending this request data to GA as event data like this:
ga('send', 'event', {
'eventCategory':'MyWidgetUserSelection',
'eventAction':JSON.stringify(myRequest)
});
?
Custom dimension where introduced with the switch from "classic" Analytics to Universal Analytics (IIRC that was in 2012), where they replaced (more or less) custom variables.
"Classic Analytics" (not an official name, AFAIK the previous GA version did not have a name other than GA) was a pretty messy thing that pretty much used the technology of the original Urchin tracker (Urchin was a web tracking company Google acquired in the early 2000s and rebranded their product as Google Analytics). Classic analytics pre-computed a lot of data on the client side (using up to five different cookies), including traffic source attribution, before it made a rather convoluted image request to the Google server.
In contrast Universal Analytics was designed on top of a clean protocol, the measurement protocol. It is "universal" because any device or program that can make a http request can now send data to Google Analytics. Universal Analytics does not compute any data on the client side, the data is processed only after it arrives at the Google tracking servers.
"Classic" Analytics had up to five custom variables in different scopes (hit, session,user)). They were displayed in the "custom" menu item of the GA interface (which is still there, but is now useless unless you have old data that was collected with classic analytics). Five variables posed a pretty tight limit, plus it was not always easy to understand how exactly they were supposed to work. So people developed a habit of storing additional data not in custom variables, but in events.
Universal Analytics in the free (commercial) version offers 20 (200) custom dimensions in four different scopes, to wit hit, session, user and product (and an additional 20 (200) custom metrics, although very few people seem to use custom metrics). "Hit scope" means you can add a dimension to every single interaction. "Session scope" only retains the last value for a session. "User scope" is primarily for values that are set once per recurring user (i.e. a user turns into a customer). With the product scope you can add additional properties to the products in an ecommerce-transaction (or production impression etc. if you are using enhanced e-commerce tracking).
Conceptually event tracking and custom dimensions are not remotely comparable. A dimension is a property that is connected to an interaction hit (or a collection of interaction hits like a session or a user) and allows to break down metrics into indivual rows. For example the "pageview" metric can be broken down by page path or page title, which are automatically collected. You might add a custom dimension "page category" and you can break down your total number of pageviews into separate rows that show the number of pageviews per category.
Custom dimensions do not have their own report; you can select them as secondary dimension in a standard report, or create custom reports based on them. You can also use custom dimensions to segment sessions or users by the respective values for the dimension.
Events on the other hand are interactions in their own right, with their own set of default metrics and dimensions (in fact you can amend events with their own custom dimensions). Proper usage of events is to track interactions that not load a new page (or do not change the page content enough to warrant a pageview call).
You can use events for segmentation (i.e. "show only sessions where the user had a certain event"), but you cannot break down pageview metrics by event properties. That is actually the main difference.
A more practical concern is that events, unlike custom dimensions, count toward you data collection limit (the free version of Google Analytics allows for 10 mio hits per month only, although the limit is so far not strictly enforced). Since custom dimension are not interactions by themselved they do not count towards the quota.
I'm building a node.js application that opens up a connection to the Twitter Streaming API (v1.1)
I would like to filter multiple keywords (hashtags & words) as separate queries. My original idea was to have multiple public streams.
However, I understand that I can only have one open connection to the Twitter streaming api per application and per IP address and that Twitter encourages us to come up with creative solutions to get what we want.
So my question is this:
If I stream with no filters, such as using statuses/sample (which I believe is 1%) and use custom javascript to filter the output, would I get the same tweets if I used the API method of filtering (i.e track='twitter').
Edit: I have created a diagram explaining this:
As you can see, I want to know if the two outputs wil be the same. I suspect that they won't be because although both outputs are effectively the same filter, one source is a 1% sample, and maybe the other source is a 100% sample but only delivering 1% tweets from that.
So can someone please clarify if both outputs are the same?
Thank you.
According to the Twitter streaming api rules, if the keywords that you track doesn't exceed 1% of the whole global traffic you will receive all data (some tweets might be lost due to network issues etc but it is not significant). This is called garden-hose (firehose is a special filter which gives you all the data but it is given as a paid service through third parties such as http://datasift.com/)
So if a tweet is filtered through public stream then it would be part of your custom filter too unless your keyword set is too broad.
By using custom filters you can track multiple search keywords, and if you miss some data because your keyword set is too broad twitter sends a track limitation notice indicating how much data you are missing.
My suggestion to you would be to use a custom filter and analyze what you get from the stream and what you get as a result for the same keywords from twitter. And when you start getting track limitation notice from twitter, it is time for you to split your keyword set into chunks and start streaming through different streamers by running them from different machines.
The details of the filter streaming is below (taken from official website https://dev.twitter.com/docs/api/1.1/post/statuses/filter)
Returns public statuses that match one or more filter predicates. Multiple parameters may be specified which allows most clients to use a single connection to the Streaming API. Both GET and POST requests are supported, but GET requests with too many parameters may cause the request to be rejected for excessive URL length. Use a POST request to avoid long URLs.
The default access level allows up to 400 track keywords, 5,000 follow userids and 25 0.1-360 degree location boxes. If you need elevated access to the Streaming API, you should explore our partner providers of Twitter data here.
I would like to answer my question with the results of my findings.
I tested both side by side in the same time frame and concluded that the custom filter method, whilst it supports multiple filters does not provide enough tweets to create an interesting enough visualisation.
I think the only way to get something more interesting with concurrent filters is to look at other methods but I am wondering if its not possible. Maybe with a third party.
I have attached a screenshot of the visualisation tracking 'barackobama' The left is the custom filter, the right is statuses/filter.
The statuses/filter api operate on all tweets, instead of those returned by statuses/sample, you can tell by looking at their tweet id's: sample tweets all come from a specific time window. So from millisecond-resolution creation time, you can definitely tell that filter returns tweets outside of sample.
For more details about getting creation time from tweet id and the time window on sample tweets, consult this post: http://blog.falcondai.com/2013/06/666-and-how-twitter-samples-tweets-in.html
I have a google analytics account for an asp.net application which determines one of many clients based on a queryString within the URL. The snippet for the GA page is located within the master page, so the GA code is consistent across all clients.
What is the most efficient process for getting a set of basic analytics through the GA portal, per client (per queryString)?
---Edit---
Off hand , but never accomplished, I want to know if I can set a variable var1 within the snippet that gets set to GA identifying a client, then get discrete but identical reports, per var1 on the users. So that var[0] .. var[n-1] = Visitors where n is the number of clients.
You can just push the unique query string (assuming it's some sort of uID) as a custom variable into analytics. If it's sequential, you can assign ranges to clients (once again, am just guessing what your setup is like).
Alternatively, you can use the uID as key and have visit frequency as the value. (here is some prototyping code to check custom var key values https://github.com/vly/js_ga_cvars)
Just remember, when you set the custom vars you have to push a pageview or event to actually pass it to GA.
If you have access to the GA Universal beta program, you have the opportunity to define custom metrics (in case of a numeric data) or dimensions which would make aggregation reporting a lot easier.
If the client is an individual person, this is not allowed by the google terms of service.
You will not (and will not allow any third party to) use the Service
to track, collect or upload any data that personally identifies an
individual
http://www.google.com/analytics/terms/us.html
I'm adding Mixpanel to my web application and I'm curious about the "process" around what happens when a user transitions from "anonymous" (not logged in/registered) to "identified" (when they register / create an account on the site).
If a user comes in and is new to the site, they get an anonymous UUID (according to the documentation). The documentation also says that Mixpanel can not translate between IDs at this time.
Does this mean Mixpanel is incapable of handling the transition of a non-registered user to a registered user, and keep track of their events from before they became a registered/identified user?
If so, does anyone have experience with working around this? How'd you go about it?
As of December 2012, you can now use the mixpanel.alias method call to alias two ids:
https://mixpanel.com/docs/integration-libraries/using-mixpanel-alias
From the above docs:
John comes to your website, example.com, for the first time. He is
assigned a randomly generated ID (perhaps 123123) by Mixpanel.
Everything he does is associated with that ID.
After clicking through a few pages, he successfully signs up. On the
signup confirmation page, you call mixpanel.alias("john#hotmail.com").
This doesn't actually change his ID - he is still being identified
using the random ID we originally assigned him.
What it does do is add the ID "john#hotmail.com" to a lookup table on
our end. Whenever we see data for "john#hotmail.com", we know to remap
it to 123123, his original ID.
So, you can start calling mixpanel.identify("john#hotmail.com") on all
your pages, and your events, funnels, and retention will all continue
to work perfectly.
There are ways to make this work. But what you are really asking for is a feature called distinct id aliasing, which would allow you to reference one distinct_id ID to another. Unfortunately, we don't offer that right now. This turns out to be a much harder issue than you'd expect due to the unique nature of the data-store we wrote for mixpanel.
In the meantime, I can give you a few strategies to get around this limitation:
When a user first comes to your website, set a distinct id for them which you generate internally. Once they register for an account, reference that distinct_id in your user detail table, and then continue to register subsequent events with that id. Each subsequent time a user auths, use the stored value as the distinct id. Hopefully when they return the cookie will still be around, and you will capture all the events without a hitch.
You could, also, let mixpanel give them an auto-issued distinct_id value, and then grab that at the time of registration by using mixpanel.get_property() then add that to your users table, and use that when you identify them in the future.
But what if they auth from one machine and then come on from another, or a different browser, or from a mobile device? Then the time in between when they hit your site and when they auth they'll be issued a new distinct_id by your site... and there is no way to alias! The solution here is a bit hackier. The only way to get that data is to log those events that were sent before the authentication (maybe server-side) and then send them via HTTP specification to the rest API with the correct distinct_id once the user auths. As long as you keep the correct time stamps, it will all appear correctly, chronologically within mixpanel. If the user never auths, then you can have the logged events time out and send them anyways.
Would either of these work for you?
When a user hits your site, identify them with a unique id and save it in a cookie if they don't already have one, then use the Mixpanel Identify API call to identify them. You can persist the unique id to your database in the user's record once they have registered, so you can re-set it in the case they clear their cookies.
If the user clears their cookies before registering, then you would be out of luck, but that's the nature of this beast and would be an issue anywhere.