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.
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.
Simplified Use case
I have a working single page web app called data_store. This app has 2 simple tasks list
List users
Show user details (when a user is clicked).
Now for this, I have 2 routes
data_store/all_user
data_store/user_detail
*For the sake of simplicity, all other factors can be ignored.
Problem: When I reload the tab my at data_store/user_detail, I loose on the unique ID of the user whose details were to be shown.
Question: How can I persist the unique ID on tab reload? and make it work seamlessly across duplicated tabs?
Failed Solutions
1st, use data_store/user_detail/<UUID> format but I cannot expose it in my URL for security reasons.
2nd, use local_storage to store current UUID, but then the reload of other tabs with different user's details breaks.
Reason: as they pick up the last set value by any other tab also.
3rd, use session_storage but the problem is that while duplicating tabs instead of opening a new one. The chrome to duplicate a tab uses the window.open and generates a daughter tab that shares all the info from its parent, including sessionStorage.
I think you can put the user's crypted identifier in the URL, If you encryption is based on a seed then it should be possible to encrypt/decrypt it, and make it unavailable for some basic hacker.
I have found this thread refering to a low level of encryption, maybe it can help you.
For a Higher encryption level, crypto-js could be a solution.
Now, if you don't want parameters in your url and don't need to support IE < edge 14, maybe you can try to get the tab id and store your data with it, so on reload it will be easy to associate data with tabs. I don't know its behavior with tab duplication tho.
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.
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.
I'm working on something similar to a pastebin (yeah, it's that generic) but allowing for multiple user editing. The obvious problem is that of multiple users attempting to edit the same file. I'm thinking along the lines of locking down the file when one user is working on it (it's not the best solution, but I don't need anything too complex), but to prevent/warn the user I'd obviously need a system for monitoring each user's edit sessions. Working with database and ajax, I'm thinking of two solutions.
The first would be to have the edit page ping the server at a arbitrary interval, say a minute, and it would update the edit session entry in the db. Then the next time a script request to edit, it checks for the most recent ping, and if the most recent was another arbitrary time ago, say five minute, then we assume that the previous user had quited and the file can be edited again. Of course, the problem with this method is that the assumption that the previous user had quited is simply an assumption. He could be having flaky wi-fi connection and simply dropped out for ten minutes, all the time with the window still open.
Of course, to deal with this problem, we'd have to have the server respond to new request from previously closed sessions with an error, telling the client side to point out to the user that his session has ended, and then deal with it by, say, saving it as another file on the server and asking the user to manually merge it, etc. It goes without saying that this is rather horrible for the end user.
So I've came around to think of another solution. It may also be possible to get a unload event to fire when the user's session ends, but I cannot be sure whether this will work reliably.
Does anybody has any other, more elegant solution to this problem?
If you expect the number of concurrent edits to the file to be minor, you could just store a version number for the file in the db, and when the user downloads the file into their browser they also get the version number. They are only allowed to upload their changes if the version number matches. First one to upload wins. When a conflict is detected you should send back the latest file and the user's changes so that the user can manually merge in the changes. The advantage is that this works even if it's the same user making two simultaneous edits. If this feature ends up being frequently used you could add client-side merging similar to what a diff tool uses (but you might need to keep the old revisions in that case).
You're probably better off going for a "merge" solution. Using this approach you only need to check for changes when the user posts their document to the server.
The basic approach would be:
1. User A gets the document for editing, document is at version 1
2. User B gets the document for editing, document is at version 1
3. User B posts some changes, including the base version number of 1
4. Server updates document, document now at version 2
5. User B posts some changes, including the base version number of 1
6. Server responds saying document has changed since the user starts editing, and sends user the new document, and their version - user will then need to perform any merging of their changes into document version 2, and post back to the server. User is essentially now editing document version 2
7. User A posts some changes, including the version number of 2
8. Server updates the document, which is now at version 3
You can still do a "ping" every minute, to get the current version number - you already know what version they're editing, so if a new version is available you can let them know and let them download the latest version to make their changes into.
The main benefit of this approach is that users never lock files, so you don't need any arbitrary "time-outs".
I would say you are on the right track. I would probably implement a hybrid solution:
Have a single table called "active_edits" or something like that with a column for the document_id, the user, and the last_update_time. Lets say your ping time is 1 minute and your timeout is 5 minutes. So a use-case would look like this:
Bob opens a document. It checks the last_update_time. If it is over 5 minutes ago, update the table with Bob and the current time. If it is not, someone else is working on the document, so give an error message. Assuming it is not being edited, Bob works on the document for a while and the client pings an update time every minute.
I would say do include a "finish editing" button and a onunload handler. Onunload, from what I understand can be flaky, but might as well add it. Both of these would send a single send-only post to the server saying that Bob is done. Even if Bob doesn't hit "finish editing" and onunload flakes out, the worst case is that another user would have to wait 5 more minutes to edit. The advantage is that if these normally work (a fair assumption) then the system works a bit better.
In the case you described where a Bob is on a bad wireless connection or takes a break: I would say this isn't a big deal. Your ping function should make sure that the document hasn't been taken over by someone else since Bob's last ping. If it has, just give Bob a message saying "someone else has started working on the document" and give them the option to reload.
EDIT: Also, I would be looking into window.onbeforeunload, not onunload. I believe it executes earlier. I believe this is the function website (slashdot included) use to allow you to confirm that you actually want to leave the page. I think it works in the major browsers except Opera.
As with this SO question How do you manage concurrent access to forms?, I would not try to implement pessimistic locking. It is simply too difficult to get working reliably in a stateless environment. Instead, I would use optimistic locking. However, in this case I used something like a SHA hash of the file to determine if the file had changed since the user last read from the file. For each request to change the file, you would run a SHA hash of the file bytes and compare it with the version you pulled when you first read the data. If had changed, you reject the change and either force the user to do their edits again (pulling a fresh copy of the file contents) or you provide a fancier conflict resolution.