separate email traffic from website traffic - http

When we click a link on a website and visit that link the HTTP request contains the previous site as the HTTP referrer. But if I click a link inside a email I have received, that HTTP request does not contain a HTTP referrer field...(clicking a link in a email received to my gmail)
So my question is, do we have a method to distinguish between these two scenarios ?
I mean any method to identify these two clicks separately using parameters in the HTTP request

I think, that when You click a link on a https page the header not contains the HTTP referrer (in php: $_SERVER['HTTP_REFERER']). And google use https, so from links in gmail the HTTP referrer not send.

Just like explained in my previous answer, don't rely on the referrer.
Just use a query string parameter like &source=email, &fromemail=true or &campaign=email.

Related

Is there a way to track an URL traffics if the page doesn't exist but was directed to a working page?

A user enters https://example.com/mypage on the browser
.httaccess redirects to https://example.com/myfinallandingpage
I would like to track the traffics of /mypage.
/mypage is not an actual page, but /myfinallandingpage is a working page.
Does anybody know a way to do this?
Out of the box you can't measure server-side redirects such as 301 or 302 since the browser JavaScript, and thus Google Analytics won't be executed on the redirect source pages.
However you can by doing a little customization:
Insert a URL parameter on the redirect destination page eg https://example.org/destination-page?ref=https://example.org/source-page and track whatever you want on that destination apge
Perform server-side tracking: you could handle your redirects at PHP level, allowing you to use a GA server-side tracking library with GA Client ID retrieved via the cookies in HTTP headers

Referral from Flickr shown as direct/none in Google Analytics

I have a Flickr account with some photos that have links in their description linking to my website. However, when checking in my Google Analytics account the Source/Medium, it appears as direct/none, although I would expect it to be flickr/referral.
I have read here that it could be due to the ad blockers, but it is not the case since I did the test with a browser without any ad blocker extension installed.
Also, according to this:
https to https = should send referral info
http to http = should send referral info
http to https = should send referral info
https to http = no wont send referral info
To track https to http:
If you use custom campaign tagging on the url then it should pass whatever info
you put into the tags as the medium/source etc.. make sure to test
that though
Other alternatives would be to:
either change the site B
to https too
or
use an internal redirection script to send visitors
to a http page on the https site before then passing them thru to the
http website
Flickr is https, my site http.
However, facebook is also https and I am getting those properly. According to this other post:
sites like facebook and similar are https but are setup specifically
on their side to allow passing of referral information
How can I make that GA shows those visits as flickr/referral?
The only solution I found is, as suggested in the second quote of the question, to use a custom campaign tagging and add the following to the link:
?utm_medium=social&utm_source=flickr.com&utm_campaign=photo
Then it will be shown properly in Google Analytics.
I found this article very useful to learn about Custom Campaigns.
Note that this does not work if one cannot edit the description, i.e., it will work for own content only.

login details(id,password) visible in plain text in browser developer tools

I am particularly new to security in websites.The day before, I logged in to my college website via my roll number, password and a captcha code. When I opened the developer tools on Mozilla, I could see one Post request (my details) being sent over the network.
I studied in my college course that there are 2 ways to send these type of details to a server. One is via URL arguments and other is through the http parameters. I clicked on the parameter tab of this POST request and I see the my login details in plain text like this :
LoginId -
Password -
Captcha - .......
Does it mean that these details are being sent as it is? or these details are only visible to me? Forgive me if it's too lame.
"Does it mean that these details are being sent as it is?"
It depends. If the request is sent through HTTP, yes. If the request is sent through HTTPS, no.
You can install a proxy such as Charles to observe. When the login request is sent through HTTP, the request URL and body are all visible, which means if someone is sniffing packets on internet, he/she can easily see your login id and password. It's visible to everyone.
When the login request is sent through HTTPS, however, in Charles the request URL would be "unknown" and the request body would be a bunch of unreadable code (encrypted). It indicates that even if someone is sniffing, it's impossible to steal valuable information. It's only visible to you.

Http referer and bookmark

I'm visiting a website and soon I click on a bookmark in my browser. A new website is opened. My question is:
Does the referer data (which is submitted to the new website) only contain the bookmark info or is my last visited website also within the data?
I'm really not sure about it.
Testing with Google Chrome and Fiddler shows that Chrome doesn't send a Referer header when fetching a page after clicking a bookmark.
An HTTP referrer is only sent if the user arrives from a resource with a URL (generally, another web page). Typing in a URL, clicking on a link in a desktop email program, word document, etc., or opening a bookmark all do not send a referrer, because those sources do not have URLs of their own.
The Referer[sic] request-header field allows the client to specify,
for the server's benefit, the address (URI) of the resource from which
the Request-URI was obtained (the "referrer", although the header
field is misspelled.) The Referer request-header allows a server to
generate lists of back-links to resources for interest, logging,
optimized caching, etc. It also allows obsolete or mistyped links to
be traced for maintenance. The Referer field MUST NOT be sent if the
Request-URI was obtained from a source that does not have its own URI,
such as input from the user keyboard.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Note that there is no guarantee that a referrer will ever be sent, even if the source does have a URL.

When browser sets the "referrer" in HTTP Request header?

I have a login page and users from different domains are redirected to this page for the purpose of SSO. I use the referrer HTTP Header field to know where the user has come from, thus on successful login, I return him/her back to his/her original domain.
But sometimes my referrer is not set, while other times it's set. Why?
Users can come to your page using different methods:
By entering the URL of your page, directly into the address bar of the browser
By clicking a link to your site from another site
By reloading your current page
By Submitting a form on your site (sending POST request back to your site)
By navigating through back/forward buttons of your browser.
By being redirected through a previous page to the current page.
Now, browsers really differ in how and when they set referrer header field. But as a general rule, you can be sure that on link click, or on submitting a form (post request), they set referrer field. Also if you have come to the current page via a redirect or a link, browser still preserves referrer header on F5 (page reload).
If you see that your referrer field is empty, it's because someone knows your Login page URL and enters that directly into the address bar, or someone has bookmarked it, so sends a GET request.
Generally, you shouldn't always expect the referrer field, because it's outside your control. You should use cookies, or query strings, because they are under your control.
the other thing is that some user may have referer option set as disabled in their browsers as a part of browser security settings.

Resources