I've looked at a couple different analytics programs (like Google Analytics) that will tell me what URL my users have entered my site from, and which URL they are going to when they exit.
It certainly must be possible to gather this data somehow, I just can't find any code examples of how to do it. I would imagine that it involves the javascript function onBeforeLoad, I just don't know how to get the URL from that point on. This is a pretty important feature, as it will help me to tailer my website more towards my users specific needs.
I appreciate the help,
Sorry, I think I was unclear originally.
One of my other sites uses a service called StatCounter, and they have a section called "Came From". This shows where users were at directly before they visited your page. So, for instance, if someone google'd "Inside Out Ministry", and found the link to my site www.insideoutministry.com, my stats page would show that the user Came From www.google.com .
What would be the code to do this?
A simple approach would be to have a db with ip, time, lasturl and firsturl fields. Every time someone calls a page, it get's checked if his IP is already in the db. if not, a new entry gets written with firsturl as the actual url and i with his ip. Every time now he loads a new page on your site, the lastpage field gets updated. I don't know how exactly to determine that he's left the page, e.G. if he hasn't accessed any page on your sithe within 10min.
To track the first/last page your users visit, you just track all pages the user visits, and the one with the earliest timestamp is the first, and the one with the latest timestamp is the last.
Related
Background and Problem
I have a system that has core users augmented by some minor contributors who only need to be able to provide approvals for certain things. To support this, the system reacts to database changes and emails those approvers with a single button in the body of the email. This button is just a link to a unique url - something like https://myapp/response/12345-abcdefg-6789.
That "response" page is listed in the web config as not requiring a log in. Thus, the approver should only have to click on the link in the email, and the system should detect that and mark their response.
In all of our testing, this works great. All we're doing is marking the response via the page's code behind, and then displaying a message on the page that the response was received. On the surface, this seems like about as easy of a task as you can dream up.
However, we're getting false positives in production. The approvers are telling us that things are being marked as approved when they never clicked the link. I assume this has something to do with their browsers checking the links for safety or something - and by performing that safety check, it's triggering the system to record the response. Unfortunately, i haven't been able to reproduce this - even when we have some of the approvers on the phone while we try it.
The question is - what is the best strategy to avoid a false positive with buttons in an email?
Lots of companies do this kind of thing - i'm looking right now at an invitation from a friend via evite. It has Yes, Maybe, and No which appear to have the same kind of setup i described above.
Is there something i should be doing with redirects after x seconds? Is there some other javascript i should be deploying on the page? Is there some other potential cause for this? The IIS logs seem to indicate that the "fake clicks" are coming from the target users computers. Which is a bit of a relief, since it's hard to imagine how some other external machine could end up at a GUID based url that is not represented by a physical file that could be crawled over in some way.
I would like to avoid having another button for the user to click, where they would click "Approve" in the email, and then when they get to the page they have click the same thing again.
Thanks!
From my understanding there are two ways to go about it. But both methods assume the current "response" page is just an intermediary.
Add another button on the page (#
https://myapp/response/12345-abcdefg-6789 for instance) that actually
submits the response (or redirects to the actual response page). It would add an extra step for your approvers but
it should work. (You can even add a captcha there if paranoid)
Once the page is loaded, redirect to the actual response page via
javascript. The idea being if the link is automatically opened by
some kind of bot it's unlikely it runs the script.
I am currently working on a task where for example an user visits www.site.com satisfying a particular condition I am supposed to make some visual transformations in the page. But this should only happen for the first time the user is shown the page. Subsequently if the user ignores the call to action and browses the site everything is normal.
To make sure that for a given session this transformation only happens once I am using document.referrer to check if it is
1. an "" string which means user might have entered the www.site.com address directly
!document.referrer.match(/www.site.com/gi); - to make sure that the user is not referred from the internal pages back again to the home page.
This works in most cases except when user gets into the check funnel the url changes to a secure one https:// and when he is referred back to site.com home page the document.referrer returns an empty string which confuses my logic a the user is entering the address in the URL
Is there any other reliable way to solve this problem. Any help is much appreciated and thank you for taking time to read my problem
function transformation(){
// transformation code
}
if(document.cookie.match(/someCookieName/) && document.location.href.match(/transformationPageURL/)){
// call the transformation
transformation();
// set session cookie
document.cookie="someCookieName=true;";
}else{
// not the url to perform transformation or the cookie is already set which means its the same session.
// but still if the user again enters the same home page url the transformation //would not appear due to the cookie being set. But the changes of normal user //visiting the website and again entering the url of home page might be less
}
I have a page “Googlesapp_welcome” is showing up in the my home page report suite and accounting for ~10000 visits per month. I know this is necessary to enable the tracking of the registration process. But what is the best way to remove it from reporting? Is it to change the sitecatalyst code on this page to not increment a visit? Is it just to filter it out of our reporting.
(But I have to keep in mind with all reporting in the future prospective)
If you want to completely stop that page from being tracked, ie no beacon will be sent to Adobe, you can set "s.abort = true". Create a function after you set your s_account variable that matches the URL you want to filter and sets s.abort = true. Keep in mind, this will really mess up your referring data as the next page view will see an internal referral as the first page view on the visit. If you are using multi-suite tagging, you will lose all beacons to all report suites.
If I were you, I would create a segment that excludes page views or visits on that page from the report suite and look at the data that way. Or, if you just don't want to see the traffic that is bouncing, create your segment excluding and single page visits that entered on that page.
Aborting the pixel is a drastic step and should be very well thought out before employing that tactic.
Use VISTA rules to accomplish the desired result.
Ok, this might sound strange but i need to somehow set cookies on site close, or maybe if somoeone knows different logic i could use to solve my problem:
I am using open source solution to track clicks on my site - http://www.labsmedia.com/clickheat/index.html .Ive change this script to add few more filters for every click such as what OS is user using, referrers, and is user new or returning for which I am using cookies - using mostly this script for cookies http://www.ravelrumba.com/blog/firstimpression-js-library-detecting-new-visitors/ .
Now the problem i have is this. First time you come to site and click, you will be marked as new user, but just with next click u are marked as returning user. Because cookie was set at start and with each click, through GET i am sending these parameters , one of them is testing if cookie exists on site, if it does it sends that you are returning visitor. You can see at this debug link - http://gjakovljevic.com/index.html?debugclickheat , at the bottom it asks "New = yes/no".
So I need solution that will mark user as new with whole first visit, not just with first click, so once he leaves site and comes back, this time his clicks will be marked as clicks from returning visitor.
Here is the link to full script -
http://www.putuj.org/clickheat/js/clickheat-original.js
line 167 is cookie function and line 239 is testing if visitor is new or not.
I hope that i explained well. I am playing with this heatmap script, managed to change and add alot of nice features but I stuck with cookies :)
well the best solution for me here is the following
have a database record of the new visitor, from its ip address and all the details you can gather on its browser he or she is using
then set a duration where in the new visitors's record is considered as a returning visitor
if the user returned with the same ip address and details check if the user already came back is already out of the set duration so it means the user is already a returning user, else he is a new user.
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.