I am using Google Analytics. It is tracking some urls which do not event exist in my site.
For example: if the site is abc.com, I can see urls like
/xyz/web.php?r=123
I think somebody has added my domain name and setup locally and implemented analytics. any way to stop unknown hits in google analytics.
maybe your applications is using some kind of url transformation example /xyz/123 to /xyz/web.php?r=123
and tracking code url is inserting like this
ga('send', 'event', 'email', <?php echo $_SERVER['REQUEST_URI']; ?>);
in php requested URL can differ from that you are entering in address bar
I recomment to use document.URL
ga('send', 'event', 'email', document.URL);
this will insert actual URL you see in your browser address bar
You can check by selecting hostname as a second dimension - if anything shows up except your domain name then see MisterPhilipps comment, you can create an "include" filter in the view settings that dismisses data that isn't from your domain (goto filters, include, hostname eq yourdmain.com. Filters are destructive, so keep an unfiltered profile as backup).
However GA will track the url from the browsers address bar regardless of if it points to an existing site. So if possible check if these are 404 pages.
A possible scenario is that somebody tried to install an exploit on your server and now checks if he can execute the exploit code by calling it via an url, or tries to find an unpatched security issue - this is especially worth checking if you use one of the more common PHP based CMS (Wordpress, Drupal etc) where "prefabricated" exploits exist (the fact that somebody checks for malware does not necessarily mean there is actually a problem, though).
Related
Is it possible to redirect visitors based on coming from website in WordPress
Your question is a bit vague. If I understand correctly you're trying to redirect base on a specific referer.
$_SERVER let you retrieve server and execution environment information. It is an array containing information such as headers, paths, and script locations.
$_SERVER[HTTP_REFERER] enable you to retrieve the address of the page (if any) which referred the user agent to the current page. This is set by the user agent. Not all user agents will set this, and some provide the ability to modify HTTP_REFERER as a feature. In short, it cannot really be trusted.
<?= $_SERVER[HTTP_REFERER]; ?>
Source # https://www.php.net/manual/en/reserved.variables.server.php
A URL was generated using Google Analytic's (GA) URL Builder (https://support.google.com/analytics/answer/1033867?hl=en).
The URL includes the utm_source and other required params for GA.
When clicking on a link with this URL the Referral Path is not available. Instead only the Source shows with an empty Referral Path. The Source is set to the value of utm_source.
However, when visiting the page WITHOUT the custom URL via a link the Referral Path is set correctly.
Why does this happen? How can I fix this?
You cannot fix this. Referral Path is available for referral traffic. If you use campaign parameters you turn your link into campaign traffic (this is obviously some unusal use of the word referrer, but Google is thinking in terms of marketing channels instead of the technical definition).
The way around would probably be a custom dimension that stores the referring url.
First you'd have to create a custom dimension in the property settings - I'd go for session level, since the referrer that brought a visitor to your site does not change during the visit.
Then you check (in the source code of your website) window.document.referrer to see if originates from your own domain (in which case you dismiss it) or from another domain, in which case you set it as a dimenson. Basic example (not production code):
if(window.document.referrer.indexOf('mydomain') == -1) {
ga('set', 'dimension1', window.document.referrer);
}
(meaning: if the name of my domain is not a part of the string that makes up the referrer url; and this would be followed by your usual page tracking).
This will store the referrer regardless and you can select your custom dimension as a second dimension or use it in custom reports (of course for CPC traffic or dispay advertising you will get google.com or the adress of the adserver as referrer which isn't that helpful, but for your use case it should work).
I have a site, let's say test.com. This incorporates Google Tag Manager. I have a console for booking, this goes to a different domain. So the form's action is say, bookings.anotherdomain.com.
When the form is submitted, the URL becomes bookings.anotherdomain.com/?_ga=TOKEN. From what I understand, _ga is the new param for all google tracking, all the utm params are stored for it in google's database.
On bookings.anotherdomain.com, for the moment this site is not fully responsive and has a "sniffer" script that redirects to mobile.yetanotherdomain.com. Yes, that's 3 different domains.
The problem is during the redirect from bookings.anotherdomain.com to mobile.yetanotherdomain.com, no GA params are passed. This redirect happens via server side.
I'm wondering if the proper procedure would be to pass the _ga variable?
$ga = '?_ga=' . htmlspecialchars( $_REQUEST['_ga'] );
header('Location: mobile.yetanotherdomain.com/' . $ga );
exit;
Would this be the right way of sending the GA params? I can't use JS for this as I want to keep it a server-side redirect, so that eliminates any GA JS script calls.
The short answer to your question is yes, forward that URL parameter if you can.
It sounds like you're using the analytics.js linker plugin, which is designed to do cross-domain tracking. Analytics.js keeps track of a particular user on a domain by storing a client ID value in a cookie. So, in order for analytics.js to track a particular user when she leaves domain A and goes to domain B, that client ID must be passed somehow. That's what the _ga=TOKEN URL parameter is -- the client ID.
In order for the destination domain to know to check for that _ga URL param, you have to tell your tracking code to expect it. The developer guide I linked to above should explain how to do that.
This site also has some good information on cross-domain tracking:
https://support.google.com/analytics/answer/1034342
I hope that helps; let me know if you want more details.
Been searching for an answer for this for a while but nothing that I can find that is useful.
Basically in the organisation I work in we use Shibboleth for user authentication.
We probably have 200+ sites & Shibboleth works effectively for these.
However, one site in particular is protected using Shibboleth (if the user is not a valid user they have to sign up for an account in this process also) which is causing an issue with our Analytics (Google Analytics). The referrer to the site is ALWAYS the shibboleth authenticator.
What we need is a facility to track conversions on this site based on source/campaign the user arrived from. The proposed solution right now is to use a Tag Manager product to fire off specific tags based on a combination the referrer or campaign. This one single site is used for a multitude of things (all prospective leads to EPR) but we need different information based on how the user landed on that page.
We are tracking all the interaction points that lead up to this (i.e. tracking potential leads) but a lot drop out during the signup process and right now we do not have actual conversion data, meaning the Marketing etc is being spent based on highest traffic source rather than which source or campaign is most effective.
The problem is when a user signs in, signs up using Shibboleth, Shibboleth sets a new cookie for that session. In Google Analytics all the referrer to this site are from the authenticator.
Is there some configuration issue with GA that I am overlooking for this scenario or is there something that can be done with Shibboleth so that the initial referrer (rather than the authenticator) being passed as the referrer which in turn would facilitate the rule creation of the Tag Manager to fire off the required tags
If you use Universal Analytics, you might be able to overcome using the new Referral Exclusion:
You can exclude specific domains from being recognized as referral
traffic sources in your Analytics reports. A common use for this
feature is to exclude traffic from a third-party shopping cart to
prevent customers from being counted in new session and as a referral
when they return to your order confirmation page after checking out on
the third-party site.
Google Analytics recognizes the URL you use to set up a new property
in your account and automatically excludes this domain from your
referral traffic, so you won’t see self-referrals in your Analytics
reports.
https://support.google.com/analytics/answer/2795830?hl=en
Another option might be to pass a parameter across the login page when you request an authentication. If you set your fields in the request correctly, you could have Shibboleth send your user back to any page or with any query string, such as adding ?source=original_page_name. After authentication, these parameters should be available to manipulate or pass on to GA. This won't actually spoof your referrers, but it will get you the data you need.
I have a contact us form in our website which would send out an email to the site admin when submitted. I would like to know from which site the user has landed onto this page and how many unique users have come here and such things... I have used Google Analytics but it sends out only information on the adword that the user has clicked. I would like to know from which site and from the user came in so that I can add this referring site when email is being sent to the site admin.
I am guessing that the referring site will always have some URL manipulation to redirect here so how can i grab that URL? or is there any other better way to achieve this?
Does the environment variable HTTP_REFERRER give what you want?
You can can begin collecting this data without adding any javascript to your Site's pages, using your server's access logs. If your server is Apache, then as long as you set your config file to record data to your access log in the Combined Log Format, then you are already collecting referrer (i.e., this is one of two additional fields appended to each line in the logfile when you specify the Combined Log Format versus the (default) Common Log Format, the other field is the user agent; both 'referer' and user-agent are taken from the respective HTTP request headers).
Another advantage of this method is that if you have been logging using the Combined Log Format, then you also have the data you want going back in time, as far back as you archive your logfiles.