Creating a custom user click tracking script. Need to know what is the best optimal solution to track user click without sending Ajax request to server on every click.
Don't require any code, just figuring out the optimal solution.
any suggestion will be helpful.
I would create an array or use localStorage in javascript to store all the clicks and targets, then simply store them every so often or when the user navigates away from the page window.onbeforeunload.
Related
I have a setup where I display a list of buttons and clicking on the buttons triggers a function that contacts a firebase database and gets the contents of a 'slide' that is to be shown to the user. The function then clears the content of the page and then creates elements from the data acquired from the database.
Now obviously, when I press back browser button once I've replaced the content, it won't take me back to the previous content. But I believe that my user's experience will be much better if it actually took them back to the list of buttons. I have two faint ideas on how to go about solving this problem but I'm lacking in specific details of how I can go about it.
Possible Solution 1:
Some way to dynamically create a new page using javascript and then serve it to the user.
Possible Solution 2:
Some way to simulate that the page has changed location. Maybe using anchoring links.
Let me know if you have any other solutions in mind or if you know how I should go about implementing these. Your help will be much appreciated. :D
I want to use the new Facebook Ads Pixel feature where I can pass through my own information about a viewer when they're unmatched to the Facebook cookie.
However, I want to do this on a checkout page, which has fields for the user to enter in their name, address etc. They do this after the page has loaded, of course.
I can pull the information from the fields as the customer types, or once the person clicks on the buy button. However, is there going to be a problem running the fbq('init'...) function more than once? I'm assuming that if I don't include the init function straight away, it won't work with my standard event tracking (to track a page view etc), so I don't really want to delay it until they click on the button as I'll lose that other metric.
Alternatively, I could do this after they've provided their information on the next page that they see.
My questions ends up as; is there a problem calling fbq('init'...) more than once on a single page and will it work to send through that extra details about the customer if I do so?
Yes, you can call init several times.
Events will be sent to every pixels passed to init.
Source: https://developers.facebook.com/ads/blog/post/v2/2017/11/28/event-tracking-with-multiple-pixels-tracksingle/
I have a bit of an issue with page formatting when I navigate away, and then hit browser back to a page.
Here is an example:
I have security questions on a form in a drop down list like so:
http://i.stack.imgur.com/ib32z.jpg
When the user selects [Type in your own question] from the drop down list, I have some jquery that animates a CSS change that pushes the form down, and makes visible a hidden field for 'custom security question'. When selected, the form looks like this:
http://i.stack.imgur.com/uVPKo.jpg
Now my dilemma is when I navigate away from this page, and then navigate back using the browsers back button, my formatting gets screwed up and looks like this:
http://i.stack.imgur.com/5Xhpi.jpg
The javascript that I have written does not trigger again on the back button so the browser doesn't know to move the form back down to accomodate the change in spacing. Is there anyway I can force the document.ready to reload or clear some kind of cache?
Thanks!
EDIT: Sorry guys, I need to reupload the images to a host and repost. Sorry for the delay.
There are basically four mechanisms for persisting state on the web:
Browser-based - the browser, if you're lucky, will save answers to form fields and re-display them when it sees an INPUT with the same name; also, some browsers will preserve some state between forward<=>back navigation
Cookie-based - pretty self-explanatory; you save a cookie with the state info, and check it later to recover the state
URL-based - navigate to a different hash of your URL, with the info you want in it (eg. "?roll_down=true")
HTML5/Local Storage - Look it up if you're interested :-)
We can basically throw 1 and 4 out, because they both rely too much on browser behavior/support, and we can't reliably rely on all browsers to handle them the way we want. That leaves #2 or #3.
Cookies allow you to save more info (as much as a cookie holds, ie. about 4k). URLs allow less info, but they have the added benefit of bookmark-ability; if the user saves the URL as a bookmark (or as a link they send a friend, or whatever), the state still gets preserved.
So, take your pick of the above, decide on how to persist your "my form is rolled down" state ... and then comes the part that (I think) you're really interested in: how do you check this state and fix things when the user clicks "back"?
That part I humbly defer to another SO post, which has already answered it:
Is there a way to catch the back button event in javascript?
so, when a user visits the site for the first time i want to show a dialog box, and when the user clicks "x" or "hide" i want to hide it from that user forever.
this only works with cookies, right?
so, when the user clears his/her cookies he/she will see the dialog box again, next time they visit the site, i assume.
or is there a better/more common way to do this?
Can you store a property on the user? It can be false by default and when you click the 'x' you can make an AJAX call that sets it to true. Your dialog box could key off this property...
This way you wouldn't have to worry about the scenario where the user clears the cookies. Of course it will only work if you have user objects server side and it is storing extra data to overcome a very small problem, so it might not be goood practice. Just an idea.
No, nor should there be. Cookies are the only means for a site to retain information. Allowing a site to do anything more is a serious breach in security.
This is a fairly common approach to stored state.
Create a user_properties table add column "firstTimeDialog" (or isVirgin) as SMALLINT with default value of '1'. when user clicks box send AJAX call to server-side to change the value to 0. Load user properties with user information into the session on login and you a very simple way of checking to see if its a users first time.
Remember a users first time should be memorable, so be gentle.
Cookies are the correct answer to persistent state, but it's not a bulletproof solution.
What if a user visits your site on one computer, and then visits again from a different computer? They'll see the message twice. Usually in cases such as these I recommend rethinking your approach.
What is the purpose of the dialog?
Is there a reason the user shouldn't see it a second time?
Can it be placed elsewhere in the page for the same/better effect?
If you really want to be nasty with cookies, you can look at evercookie. But please only use your powers for good or for awesome.
I'm having hard time trying to figure out how to auto-save user data in a form when the browser is being closed or user changes the page. The onBeforeUnload event is OK when you want to open a dialog box, but by then it's too late to save the changes (except if you just block the browser in the onBeforeUnload handler long enough for it to pass the request to the server...but I'd rather not do that).
I am sure some of you have had to deal with the unsaved form problem. What do you do? Do you:
let users just lose their changes,
ask them using a modal window if they are sure they did the right thing,
save individual fields on the fly as they change,
or do you have some ultimate method to automagically save the data when it's about to be lost irretrievably?
•ask them using a modal window if they are sure they do the right thing,
Closing a window is an act of cancellation. As the user never actively submitted the form, theres no guarantee that they want the data saved (it may not be correct), and you saving the data could cause problems for the user.
I like your third option:
save individual fields on the fly as they change.
I'm having to deal with a similar situation, and that's what we are doing. The two main things that sell that to me:
Improved user experience - the user
will be impressed by a form that
does not lose changes. They are
'committed' once they are validated.
E.g., he types in a valid email
address, and it is saved instantly,
furthermore he is provided some sort
of feedback for each field that is
successfully been saved (a green
tick for example, appears next to
the field).
No more 'oh crap my browser crashed
and I lost all my info' situations.
Disadvantages: The extra man-hours involved in developing such a solution, and the possibly that it ends up not degrading as nicely as a simpler solution. That said, it is still worth it IMO.
In any browser I have used it in, onBeforeUnload provides you with a modal window which asks the user to confirm whether they want to leave the page or not. You can added your own text warning them that there is unsaved data, to help them decide. You don't want to explicitly save without the user's request, because a) the user did not attempt to save, and b) if you need to throw any validation errors it will be too late as the page is already in the process of navigating away.