I'm starting to run a few ads on a website, and I'm trying to decide the best way to track performance.
Specifically,
What's the most efficient way to count clicks? About the only way I can think of is to link the ad to another page with the ID of the ad as an argument (e.g. adserver.aspx?id=1234). The other page would then update the database and do a redirect to the advertiser's link. However, it seems inefficient to have to load a separate page for this. Are there any other options?
Also, it seems like I might need to know stuff like how many clicks occurred in a given week. But storing a separate database row with a date for every single click seems excessive. Has anyone else done something like this? Would it make sense to maybe create a new row for each week and increment a counter for all clicks that occurred that week?
Any tips appreciated.
I would suggest that your first solution is the best option, in fact it is the design that most similar systems (OpenX, Google AdSense etc) employ. Additionally it helps you better managed your banners and prevents your site leaking search engine spiders.
As for performance that is just a question of having a good design, in a typical design the redirection script will be fairly lightweight so should process requests fairly quickly. It is worth mentioning that you could thread off the DB updates to reduce the redirect request response times.
There is of course another option:
Rather than homebrew your own banner serving scripts look into implementing OpenX instead, it is free and an extremely good piece of software. OpenX can be found here:
http://openx.org/
and here for the open source version you can run on your own server:
http://www.openx.org/publisher/open-source-ad-server
Another option would be to implement something like Google AdSense and save yourself the hassle of finding advertisers etc. Google also provides tools to allow you to sell banner space and then fallback to default AdSense banners if you have no active advertisers (OpenX will also do this and also support integrating AdSense (and other advertisers))
You can do it with JavaScript.
Opening the page:
Send the ad URL to the client
When the user clicks the ad, use JavaScript to open the URL. Or, simply use an anchor with target="_blank".
Logging the click:
Either way, hook a JavaScript function to the ad click event.
When the user clicks the ad, use AJAX to call a web service. The web service will then log the click.
This way the ad opens as soon as possible, then the browser asynchronously communicates with the server for logging.
The question is, what happens if the user clicks the ad, the page opens, then the web service call fails? If you would prefer, you could call the web service first, then and only if the call succeeds, open the ad. Probably not the best from the end user's perspective.
For you question #2: Storing each click gives you the most reporting flexibility later. If you are set on weekly reports, why not set up a weekly process that generates the reports you need, then cleans up the data? You could even skip cleaning up the data for now until space or speed becomes an issue.
Would it make sense to maybe create a new row for each week and increment a counter for all clicks that occurred that week? Probably not. Only one process can update the counter at a time, otherwise you'll lose data. The locking that has to occur to get the value then update it will probably significantly slow down.
Related
I want to measure the time spent by a user on web pages. It's doesn't include the time when a user navigates away from the browser.
I found few open source libraries like Timejs library which can measure the time spent by a user on a web page, but when a user is watching a Youtube video on the page, these libraries don't measure that time.
.
Is there a way to handle this case or any other library which handles this case?
Actually, these libraries fail to calculate the time spent by the user inside an iFrame.What is the best way to know when a user is active in an IFrame?
How does Google/AppNexus/Motomo calculate interaction time? Is there a common design/architecture that they follow?
PS: I am trying to integrate the library with my react App. If there exists any similar method to solve this problem in React. Please let me know in comments/answers.
Thanks in advance
HTML5 Page Visibility API is the answer of your question.
You need to just listen an event as per the browser and it will be triggered every time when user will jump to another tab.
Look to Page Visibility API
There is a good and security way to do it but you need webSocket implementation.
Make special socket client and server for this feature.
When you client is disconnected you can count that your user is not anymore on page. Implement timer's for time log on server part.
Page Visibility API look like solution for local calculation(unprotected). If you work with money or some kind of value's better use server for validation.
p.s.
If you have a buggy situation with timer ( on inactive tab ) then use HackerTimer library (combination with web workers).
Just start a timer when the user enters the page (lots of ways to do this) To pause and continue the timer, try using the onunload() and unload() events (they may not work exactly as you want it to, but it is the best thing I could find. Take a look at this to help you https://www.w3schools.com/jsref/event_onunload.aspHope this helps!
I'm developing a website that is suppoused to control some devices that rotate when pushing one button. However, I only want one user at a time to be able to push the button.
That is, when a user enters the page, check if it is the "first" or only user that is there. In case he is, he can use the button freely. In case he isn't, the button appears as disabled.
What would be the best way to implement this? I'm using a classic design of html+js+php.
Thank you.
This is a design question, and still, you should have already tried something and post that something before asking here.
You should use a lock system:
create an endpoint with php, to call with Ajax that checks over a variable globally shared (better if on db) that acts like a semaphore, the first who arrive make it red and 'acquire the lock'.
If the lock is acquired, the client can do the action,
If the lock is not acquired, someone else took it already.
Do not forget to release the lock after the action.
You can use the same call to acquire the lock, do the action and release the lock. If the lock is not acquired the call return an error message and the user will know which is the issue.
P.S.
If you was thinking about a real time system, you may consider using websockets or just the system above with different calls for acquire the lock and do the action (and poll for the lock status).
To track a user on a website is not that difficult, but check if and when he/she leaves is the challenge.
If this is not time crucial you can do this with timeouts.
First, you need to be able to track the current user on your site (maybe with sqlite, textfile, mysql/mariadb) (maybe identified by IP) wich is updated a user loads the page.
After a timeout the tracking storage can be updated and the next or new one can hold the button.
If you need this realtime, you need a bit more to do. In this case I would use Websockets or NodeJS to keep connections to your page wich in fact you can use to keep track on active users and wich one should be able to keep the button.
Just keep it like a realtime online chat without texting. There you need to keep track of online users as well.
(Websockets or NodeJS are here only a example, there are alot technique to archive realtime "collaboration".)
Some background, the environment I am working in is PHP on the server side and Javascript on the client side. To track a user session, I make a JS PUT request to a server every 5 seconds. Through this I get the amount of time they were on the site, scroll depth, click events, etc.
With tools such as MixPanel or Google Anaylytis, they have the same metrics being measured, yet there isn't constant js calls being made. So my question is how are they tracking the user without javascript?
Your question seems to be... "how does google analytics know how long a user spends on a site without sending constant updates"? Well, short answer is that it doesn't (but it can, read on...!)
In the simplest setup, it will create a session when the first page is opened. Then it will track the time until the second page is opened, then the third. But it doesn't know when the third page was closed, so the total time for the session will only be "time page 3 was opened" minus "time page 1 was opened". And that's what you'll see on the analytics page. This is how most analytics systems work and yes, it's innaccurate. But that's how it is.
HOWEVER! There is a way around this, and it's called an "engagement hit" - essentially just tracking when a user does something on your page, e.g. playing a video or clicking a banner. In fact, you can track all sorts of events with Google Analytics and this will all help towards accurately reporting time-spent. This will involve more JS calls being made than just the typical onload event, but they certainly will not be constant (unless you set up some crazy events).
There's some good information about this on the GA docs site. It might be worth having a look and trying to implement something similar.
Say, a link to a person is sent to a user via email. If the person is already logged into the webpage in his/her browser, clicking on the link takes him/her to the page. However, if he/she is not logged in, he/she should be asked to login in order to access the page. Is there a way to achieve the above functionality using jquery, javascript?
Yes. Build a back-end authentication system, using AJAX and whatever your server-side language is.
From there, develop a hypermedia-style of content-system, and a modular, "widget"-based application delivery model.
Within your hypermedia responses to login (plus passing whatever relevant path information was gained from the e-mail), either redirect the page to a new page (based on the linked response from the server), or download the widgets requested from the server (for whatever application you're displaying media in), and then stream in AJAX content (again, from a URL dictated by the server-response).
This is about as close as you're going to get to security, in terms of delivering things to the client, in real-time, with authentication.
If you were to load the reports/gallery/game/whatever, and put a div over it, and ask for users to log in, then smart users can just kill the div.
If you include the content, or include the application components (JS files), or even include the links to the JS files which will request and display the content, then clever people are again going to disassemble that, in 20 seconds, flat.
The only way I can see to do this is to have a common request-point, to touch the server, and conditionally load your application, based on "next-steps" URLs, passed to the client, based on successful authorization and/or successfully completing whatever the previous step was, plus doing authentication of some form on each request (REST-based tokens+nonces, or otherwise)...
This would keep the content (and any application-structure which might have vulnerabilities) from the client, until you can guarantee that the client has been properly authorized, and the entire application is running inside of multiple enclosed/sandboxed modules, with no direct access to one another, and only instance-based access to a shared-library.
Is it worth the work?
Who knows.
Are we talking about a NORAD nuclear-launch iPhone app, which must run in JavaScript?
Then no, engineering this whole thing for the next six months isn't overboard.
And again, all of this security falls over as soon as one person leaves themselves logged-in, and leaves their phone on the table (biometric authentication as well, then?).
Are we talking about a gallery or discount-offers that you want to prevent people to log into, so you know that only the invited people are using them?
Well, then an 18-month project to engineer, develop, debug and deploy a system like this is probably going to be overkill.
In this case, perhaps you can just do your best to prevent the average person from stealing your content or using your cut-prices, and accept that people who take the time to dig into and reverse-engineer everything are going to find a way to get what they want, 95 times out of 100.
In that case, perhaps just putting a login div overtop of the page IS what you're going to be looking for...
If you're dealing with, say a company back-end, or with company fiscals or end-user, private-data, or anything of the sort, then aside from meeting legal requirements for collection/display/storage, how much extra work you put into the security of the system depends on how much your company's willing to pay to do it.
If it makes you feel better, there are companies out there that pay $60,000-$150,000 a year, to use JS tracking/testing programs from Adobe. Those programs sit right there, on the webpage, most of the time, for anybody to see, as long as you know where to look.
So this isn't exactly an unknown problem.
Yes it is. By authenticating (login) you can store a "loggedIn" cookie which you have to delete by session end (logout or closing the browser). You can use that cookie to check if somebody is logged in or not. If not logged in, than you can display the login page and send the login request with ajax. Btw it is not a good practice to use hybrid applications like that. It is better to use SPA-s with REST service, or implement this on server side.
I am trying to prevent fraud in a webproject I am building.
The project is a game which includes multiple websites.
Each website does a ajax check for with each pageview to a webpage on my server for a status update of the game.
The response page, lets say www.domain.com/response.cfm (it is coldfusion) normally returns nothing, but at a certain point of time within the games timeframe, it will display a JSON string with information.
This information is then used by the script that is included on the websites.
So website A has been viewed 100 times (all of its pages), which will generate 100 ajax calls.
The problem I have is that a robot could check the ajax destination too, and much faster. Now I can detect a robot, or could make it difficult for him by using a session or checking for cookies, BUT...
the biggest issue is that I found out you can do a lot in the Firebug script console, or the Safari console. Probably Chrome too.
With this console, they can even evade the crossdomain restriction. I created a simple script that does a couple of calls to the Ajax page and when I go to the same domain first, and then use the console...there is no crossdomain limitation. And you execute all kind of javascript, so in essence someone like me could commit fraud in the game by using the javascript console which masks him as regular browser user.
My question now is: Does anyone know how to prevent this? I tried to disable the usage of the console but I don't think I can. It may be possible to detect if the console is active and then disable MY scripts so the game doesn't work. But I think they can load the script source in the console manually and then the game does work.
Looks like console is a beautiful thing, but a nightmare for me now to prevent people cheating in the game I am creating.
Hope anyone has suggestions.
ps: of course I am trying to implement som server side checks to detect cheating, but most of the time it is not realtime.
UPDATE 19/3/2012
The fraud that I am trying to prevent is cheating in the game by polling the page that generates logic for the next step of the game. This is a serverscript page which generates json code which will trigger a change on the website the game is played on. For your information, websites the are involved have a script in there header, like google analytics, so they will communicate with my server every pageview.
Polling that serverpage can reveal information which will gain the cheaters knowledge or progress.
So i have to prevent people from getting knowledge ahead of other earnest players by monitoring the serverpage which will reveal information at a certain time. I don't want them auto polling it and when info is revealed, the send themselves a notifcation and check the website.
So what I will do is make sure that if people have to many pageviews per second, they are blocked. Plus you need a cookie to be able to join in and you only get a cookie by logging in. Hopefully this will give me enough tools to make it as robust as possible.
Thanks for all your knowledge, people.
It would be very, very difficult to disable web consoles across the majority of browsers, and anyone who managed to do this would probably be exploiting a browser bug. But read on...
First rule of web programming: You can never trust anything you receive from the web client. Anything that gets sent to your data might have been forged or altered intentionally or unintentionally, and even if you did manage to block a web console, what's to stop me from opening it in a different browser which specifically disallows websites with the console? So that's out. As #DCoder mentions in the comments, there are other methods as well, including browser extensions, which would allow user-defined JavaScript to be executed.
So any checking you do has to be server side. I know you're trying to do some checking already, and it's hard to give advice without having more specifics. That said, one way to do this, as far as I can see right now, is to issue each client an ID and store that in a database somewhere. They can't be sequential IDs, and make sure that they're not trivially forgeable even if someone has a bunch of different IDs (for example, you might want to salt the username, and then hash it). Each time a request is made to the server, only issue a response if the last request was >500 ms ago, and update the database accordingly. Expire the ID after logoff or some time.
The first thing you should think about is securing your server, not the client. It's impossible to hide client code from the client. While it might arguably help prevent a few people who want to cheat from cheating, it's not your primary objective. You have to do this from the server side. This means validating the requests on the server to ensure that they conform to your expectations to some degree.
Game companies will
Require user authentication of some kind so they can identify users
Create some rules about possibilities. For example, the laws of physics should apply, so you know when someone has cheated. Something they can validate as human activity.
Ban people who cheat
If you are not sending data continuously over the network, then you have an issue which is unsolvable unless you are willing to make checks on the server securely and continuously over the course of the game. This will increase server load, but that's the unfortunate cost of preventing cheats.