Trying to create a simple segment to excludes a referral source retrospectively (a spam site called trafficbot.link) from all analytics views.
I can:
…set Traffic Sources > Source > contains / starts with / exactly matches, and it will correctly show ONLY the spam/fake accesses (the percentage of users and sessions on the right is refreshed in real time).
I can't:
…do it the other way around, i.e. use does not contain / does not exactly match / is not one of.
The total stays stuck on 100% of sessions.
Am I missing something obvious?
I note this answer which has no input other than from the original questioner, suggesting Google say it's "not possible" to exclude existing requests - surely it is? Isn't that the whole point of segments? How are you supposed to filter out spam otherwise?
(I'm aware analytics filters isn't retrospective.)
You are talking about segments but the link you entered refers to filters.
Anyway, retroactively you can apply a segment to see the data without the spam one, you can use an advanced segment, choose conditions and exclude sessions that contain for example browser size equal to (not set).
https://www.fortop.it/journal/tieni-lontano-lo-spam-dai-dati-google-analytics/
I'm getting some very strange behavior in DTM. When our page loads (from a local instance of the website) we get the expected call going out with the proper dev report suite. When a custom link call is made from that page, for some reason DTM sends it with a production report suite. If I look in Adobe Analytics for the custom link name reported under the prod RSI, it does not show up in there.
Any ideas on what is going on and how I can fix this issue?
This is my shot in the dark based on what you have said, and it is based on the assumption that your statements are true (e.g. you aren't seeing pink elephants, that the request was indeed showing your prod rsid in the proper portion of the request url, that you did in fact check your prod rsid after an acceptable amount of time has past, no segment or other filter shenanigans, etc..: in short, that you do know how to accurately perform the basic QA song and dance).
Under that assumption, the below is a scenario that can plausibly reproduce what you are describing. I could be partially right or totally off for your specific situation, but there's really no way for me to know for sure without having access to your DTM instance.
The Scenario
Long story short is it sounds like you have a blend of custom code and DTM automatic settings enabled, and DTM is overriding and/or not caring about your custom code for link tracking.
More specifically, it sounds to me like you have AA implemented as a tool in DTM, and in the config settings, you have your production and staging rsids specified in the text fields.
Then in the General section, you either do NOT have values specified for Tracking Server and Tracking Server Secure, or else they are set to the wrong values.
Then, in the Library Management section, you have either selected "Managed by Adobe" in which case DTM takes care of the library, or else you have selected "Custom" and you are adding the library yourself AND you have NOT checked "Set report suites using custom code below".
Then, somewhere in DTM (e.g. the Library Management > Custom code box, or Customize Page Code codebox) you have code that pops rsid stuff (e.g. s.account, s_account, dynamicAccountList stuff), and possibly also trackingServer and trackingServerSecure.
Finally, you (like most other people, because DTM's double script include for staging vs. prod is.. dumb) just use the prod script include on your page, and either use the debug/staging mode or rely on whatever rsid routing logic you've setup to route to dev.
So.. when the page is first loaded, DTM loads the AA library and it sets variables and stuff based on what you specified in the tool config. During this time, it is also popping any custom code blocks you have in the tool config, which may or may not override what you have specified in the tool config fields, depending on what you enabled. Then after that, it pops stuff you have in page load rules (if any), etc..
But then comes the link click.. As I have mentioned in other posts on SO, DTM has this caveat (IMO bug) about how it references the AA object after the initial page load/AA request: basically, it doesn't. Instead, it makes use of internal methods (the main one being a .getS() method) to create a new instance of the AA object, based on whatever things you have configured in the tool config section. Well here's the rub.. it does NOT account for or execute any custom coding you have done in code boxes in the tool config section.
So that basically happens whenever an event based or direct call rule is triggered, and it effectively screws you. Why does DTM do this? I do not know. IMO Adobe needs to change this feature caveat bug. Either they should refactor DTM to execute the code boxes, OR they could, you know.. just reference the original AA object created, like any normal script would do..
But in any case..
So for example, my theory here is that page loads fine, points to dev rsid based on your setup. But then you click a link and an event triggers, and DTM makes a new AA object not caring about your custom code, so all it has to go on is what you have in the tool's config fields.
Since DTM doesn't actually have any rules around the prod vs. dev rsids you specify in those fields (you have to write custom code in the custom code boxes - that DTM ignores!), it just pops the prod rsid, because that's the script include you have on your page.
Then as far as not seeing the data actually show up in your prod rsid: again, since DTM ignores what you set in your custom code boxes, it's defaulting to what is specified in the trackingServer fields in the tool config, and my assumption here is they are either blank or wrong (you should be able to look at the request url to adobe to verify this). This theory is because you said the prod rsid is right, and you see a request being made. So the next culprit would be wrong tracking server specified.
So, that is my theory of what's going on. Maybe it's all right, maybe it's some right, hopefully it may point you in the right direction at least.
Edit:
If you can confirm that this is indeed how you have things setup, then you will naturally ask "Okay, well what do I do about that?". As I have said in a lot of my other SO answers.. basically, your only option is to uncheck all the settings that make DTM automate AA, and in all your rules, keep the AA section disabled and whatever AA vars you wanna set, set them yourself and make the s.t() or s.tl() call yourself in a 3rd party script code box, so that it continues to reference and pop based off the originally instantiated AA object.
Update
Based on your comments below, okay so yeah.. that sounds like what I described, and accounts for prod rsid popping. As for data not showing up in report.. so if you are certain tracking server is set correct (the request url looks good) then this isn't a DTM issue. Here are some other explanations for why the data wouldn't show up:
Are you sure the request is being sent to your prod rsid? I don't know what you are looking at to verify this, but this is where you should be looking: In the request URL to AA: "http://[trackingServer value]/b/ss/[s.account value]/1..."
Click request isn't making it to Omniture. Verify in a packet sniffer that the request is actually made and that you are getting a 200 OK or NS_Binding_Aborted response.
You aren't waiting long enough to check for the data. Even basic hit data and looking at "real time" reports takes a little bit of time to show up.
You have a segment/filter active that's not jiving with the data you are trying to look at. Make sure that you don't have anything applied. Or, if you are using those things to find your data (and aren't seeing it), ensure that you are correctly applying it.
You recently created the rsid and the "go live" date hasn't passed yet. Data will not show up in the report suite until up to 24 hours after the specified "go live" date.
You have a vista rule in place that's affecting data showing up. Some companies have a vista rule in place for a number of reasons and there are a million ways it could affect data (e.g. routing to a different report suite). For shits and grins, check your dev (or other rsids) to see if your data showed up there. Even if that doesn't make sense, at least it's a step forward.
You have a bots / ip exclusion rule in place that's catching data from your location.
The data sent in from the link click isn't relevant to the report. For example, maybe you are looking at e.g. prop10 report and prop10 isn't actually sent in the click request.
I know a lot of these are basic things to check, and no doubt you've checked, but check again. Have someone else check for you to be sure. I'm not questioning g your abilities here, but even the best of coders forget to cross their t's and dot their i's sometimes, and manage to miss obvious things. If you are sure about all of these then contact Adobe ClientCare because I really can't think of anything else that wouldn't involve an issue with Adobe's backend.
I ran into a similar problem with my implementation. Essentially what I did was set the s.account variable directly inside the doPlugins, so it would be set on all tracking calls. I wrote specifics here also: DTM Tracking Account
I am implementing cross domain tracking for a client. We will be using Universal Analytics with Google Tag Manager.
Let's say the client has three domains: example.com, example.de and example.se. We would like to have a master account that tracks everything, but we would also like to be able to drill down and see a single domains stats. Perhaps this already exists without any customization but I have been unable to find anything on how though.
What I can see there are two ways to go about:
Create a filter that automatically appends the domain to the tracked data. So instead of /about in my view, I would get example.com/about and example.se/about. But how would this work with event tracking? Is it possible to get a report the way the client want's?
Use custom variables and dimensions. This way I could set up a variable for Domain and send in before tracking the data. But will it be sufficient to get the reports wanted?
Appreciate any help.
Thank you,
Bjorn
Hostname ist already tracked, you can set it as second dimension to break down pageviews etc. by domain (works with events, too). However that is really cumbersome and most people follow the route you have outlined in Point 1. (Google suggest that themselves in their filter documentation) - however you'd still need hostname set as second dimension to break down by domain in the events report (or you create custom reports filtered by hostname for events for each domain).
Or you create segments based on hostname (since you can compare up to for segments that would allow you to compare the overall performance and domain performance).
Plus of course you can create additional views filtered by hostname and add the domain name only in the rollup-profile for all domains.
So there are several ways to do this somehow okay-ish, but nothing really better than the solutions you already came up with yourself.
Been trying to get this working for a few weeks now. Any help is greatly appreciated.
I have recently upgraded to Universal Analytics and managed to successfully set up cross domain tracking with the autoLinker but I can't get my Analytics Experiment to pass the _ga variable when redirecting the user to a domain part of the experiment.
Setup
Both domains have two trackers, one (t0) which they share [UA-xxxxxxx-5] and one (domainUniqueTracker) which logs to a trackingId unique for that specific domain ([UA-xxxxxxx-1] for main domain and [UA-xxxxxxx-14] for new experimental domain).
Linker is loaded on t0 to enable sharing across domains.
Linker is loaded with an array of domains, including the domain I'm trying to send traffic to via the experiment.
Experiment is created on shared trackingId [UA-xxxxxxx-5].
Context
My company has a product called LIME Pro where we until now have had info about on our company web page. Now, as an experiment we have created a one-page about the system on a separate domain, and they want to see which page (old or new) attracts most leads.
Old product page within company web page (experiment code installed there)
http://www.lundalogik.se/crm-system/lime-pro/
New product page on separate domain (shares trackingId with main domain on tracker t0)
http://www.lime-pro.se
Problem
If I visit www.lundalogik.se and from there click on a normal link to the new, external site (normal anchor link on dummy-page lundalogik.se/experiment/) the clientId is successfully passed along in the URL and the tracker at the external site recognises this and starts using the clientId.
But if I browse to the page where the experiment code is installed, I am redirected to the external site without the clientId being passed along, so the tracker at the external site generates a new clientId.
Thanks and sorry about long post, wanted to explain in as much detail as I could.
The various linker functions in UA add _ga to outgoing links (form, frames etc.). Since the redirect happens in the experiment javascript the client id cannot be added to the url (which in a way seems to be an oversight on Googles part - it seems they did not anticipate your use case, i.e. content experiments across domains).
I have a few untested ideas to contribute, maybe you can build a solution on top of one of them.
1) Before the experiment code fires push the client id to window.document.location.hash. At least in Chrome this does no cause a reload (as far as I can tell from looking at the network tab). Since the hash is now a part of the url it should be sent along when the redirect fires. Then you need a script on the receiving page that checks the hash for a clientID and passes it to analytics if present.
2) Basically the same, only this time with the pushState method (https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Manipulating_the_browser_history) which should allow you to provide the query parameter without reload.
3) Make the variation page a page within your main domain. Instead of any content put a javascscript there that reads the clientId from the cookie and redirects to the other domain
4) Same as 3, only serverside (don't forget to include the content experiment parameter in the redirect)
As I've said this is basically thinking aloud but it might provide clues toward a solution.
My apologies for only having half an answer but I got orders from above to drop this before I got it fully working. Hopefully it will still be somewhat helpful for someone looking to do the same.
If you do get the receiving part done, please post your code here and I'll update this answer/reward you with the answer.
OK here goes nothing..
The sending side works and adds the clientId to the hash and it is successfully transfered when the experiment does a cross domain redirect.
PAGE WITH EXPERIMENT CODE
Execute this before you run the experiment code.
var z, y, x = document.cookie.split("; ");
for (var i = 0; i < x.length; i++) {
y=x[i].split("=");
if (y[0] == "_ga") window.location.hash = y[1];
}
PAGE ON CROSS DOMAIN
Here is where I never got to before receiving my orders to drop this. But you would do something like:
checking window.location.hash and if it contains a clientId (window.location.hash.substr(0,3) == "#GA")
check for existing cookie
2.1. (exists) split cookie by "; ", find "_ga" and replace it's value with above hash (remove "#" first)
2.2. (doesnt exist) create a new cookie at domain level and set "_ga=(hash-value)"
initiate google analytics tracker which would assume the visitor already had accessed the page before and accept the client-id from the cookie
live long and prosper
So, sorry again for an answer is only partially complete but hopefully someone will benefit from this.
Or at least not assume they are mad like I did when I couldn't get it working :).
If the community would like I will of course remove the "accepted answer" if this is considered bad practice (this is only my second post ever to the SO network).
I've spent last few days trying to find a solution to solve problem below.
I have set of URLs for which I would like to request data - mainly pageviews and visits by months in specific time interval. These URL specify one web section and we would like to get statistics for this section. I'm using PHP GAPI.
I am able to construct correct filter for the URL set:
ga:pagePath==[url1]||ga:pagePath==[url2]||ga:pagePath==[url3]...
But this works for a fews URLs because request is sent via GET and there is request length limitation for GET.
At first I tried to make severeal requests for a few URLs from the whole set and after all requests (when I had data for all pages) I made sum of pageviews and visits. Than I realized that this could work for pageviews but not for visits (one particular visit could be counted in more than one response and thanks to sum it was counted muliple times).
And than i have these limitations:
I can't use regular expresion to shorten the filter. URLs of pages are badly designed (not thanks to us :) ) and the pages in a web section therefore don't have nice URL prefix like /my-section/*
I need historical data (2 years back), so it won't help to start tracking some custom variable or event for pages in particular web section from now.
So I tried to make POST request to API. I was able to get auth token, but POSTing request to get statistic data returns:
403 Forbidden
Target feed is read-only
I tried to find if there is actualy the possibility to use POST method, but had no luck finding exact info (some clues suggest that it is not possible).
Another idea could be redesigning URL to have some nice prefix to filter by regexp and somehow changing the stored URLs in GA, but I have a feeling that it's not possible either.
Does anyone have an idea how to solve this?
Thanks for any suggests :)