Is there a way to log how long a visitor stays on my website?
Write some JavaScript ping function to send heartbeat requests every few seconds.
That is, if you wish to do it manually. Otherwise, use some statistics software. Many hosters put something for you to use. Or just add Google Analytics to your site.
Following Developer Art's suggestion, there is a very good implementation of this heartbeat method at ajaxpatterns.org.
Some services/tools: Google Analytics, Piwik, Woopra, ...
Google Analytics will record the time between pageviews on your site. This means that single pageview sessions (bounces) are not factored into time on site, nor is the time spent a user spends on their final pageview for multi-page visits. It'll give you a decent ballpark figure though.
Related
I have been putting out fires all day. Can't seem to make heads or tails of this error...
Today I started for the first time after months of using the same script. It is triggered when a new record is added to a google sheet.
It seems to work on and off but every few minutes I am getting a failure notice indicating "Service using too much computer time for one day".
Looking through the documentation and the post on Stack, it is clear I am not the first to deal with this issue, but there does not seem to be any concise answer to how to resolve. I looked for some way to reach some type of google assistance but am always directed back to stack overflow to submit my issue for consideration. Understand this could be an issue with my script, but cant seem to find what might be causing this issue. Also confusing the matter is that the script does seem to be firing 90% of the time.
My questions:
How do I check the "computer time" quota?
Should I turn off that script/trigger until 24 hours have passed?
Does anyone know how to get a hold of Google support directly?
I don't know of any way that the total script run time can be seen in a dashboard.
You can see duration times of individual script executions at:
https://script.google.com/home/executions
You could scroll through your executions to look for long durations times. That might indicate an endless loop in your code.
To calculate the total run time of all your running scripts, you'd need to use the Apps Script API.
https://developers.google.com/apps-script/api/how-tos/view-processes
https://developers.google.com/apps-script/api/concepts/processes
I don't have any code to list and compile all the durations.
If anyone does, that would be very interesting.
I don't know if deleting the trigger until the next day would gain you anything. I'm guessing that it shouldn't.
Google does not provide "on demand" support people to answer questions about Apps Script. Even G Suite customers don't get "on demand" support contacts for Apps Script. You can report bugs and request features through the Google Issue Tracker, but that won't get you direct contact with a Google support person. Even if you purchase a support plan, Google doesn't have people who are designated to support Apps Script. If you purchased a support plan, they might try to help you with an Apps Script question, but officially they aren't qualified to help, or obligated to provide Apps Script support. And even if a support person tries to help you with an Apps Script problem, the first thing they'll do is a search of Stack Overflow, and give you links to SO posts.
So, it's extremely unlikely that you're going to be able to talk with someone directly at Google.
The best thing to do is to review your code for performance issues. Avoid reading the writing data often. The ideal situation is to get all the data that you need just once, process it, and write it back once. Cache data if you can. Avoid lots of calls to Properties Service. Find what part of your code is taking the longest time, and try to improve it.
I've been looking at my Google analytics account and noticed a surge in the bounce rate. Is it possible the PINGDOM uptime monitor is causing this increase? There seems to be a correlation between the two.
Many thanks
That is very likely since Pingdom's uptime monitor makes a HTTP(S) call to page(s) on your website to verify that they're up. You can avoid this simply by excluding their IP addresses from being logged as visits by Google Analytics by adding them to GA's exclusion list, as documented in the Google Analytics help pages.
I think it cant increase your bounce rate. cause analytics filtering bots, but if you sure that pingdom run analytics.js and was not filtering by default, you can add they domain/ip in custom filter (in view).
As a first step, you could check, if increased bounce rate can be credited to any traffic sources. This might already be linked to Pingdom as a referrer. You should also check with Pingdom FAQ or Support, whether they run your scripts during their measurements. E.g. this product or product feature of theirs claims to run javascripts.
If scripts are executed during measurement, then Analytics scripts are also very likely to executed, and therefore a call will be made to GA servers for your site. In this case, solutions mentioned in other responses can be used, e.g. filterin based on traffic source's domain or IP.
If scripts are not run, then you'll have to look for other reasons behind. Again, traffic source base breakdown of bounce rate could be a good place to start.
I want to show the amount of visitors for a Bolt page in the frontend. I could not find a proper solution for this in the docs or in the extensions.
Is this possible with Twig? Or should I use a third-party solution?
From the point of view of Twig, no. You would need a reliable way to log each visit, remove bots and crawlers and still no trash your database.
I wrote something for WP once, well twice actually, that attempted to do the visit tracking but it ended up putting a lot of pressure on the backend to track things that people like Google had far better resources to handle in terms of a) knowing what should be considered a 'real' visitor, and b) storing/processing the associated data.
What you however could do, implement Google Analytics to log the visitors and then use the API to display visitors on the front-end.
Might be quite a hassle to figure out how the API works for certain pages, but it will solve your problem.
Good luck!
Also see https://developers.google.com/analytics/
In Salesforce I have created a future method that makes a Google Maps geocode callout. I know there is a limit of 2,500 requests per day but our instance has made no more than 100 requests today. Maybe the same number of requests yesterday. Yet the response code is 620 G_GEO_TOO_MANY_QUERIES.
Could it be that Google is seeing the IP address of the instance of Salesforce and aggregating all of these requests as coming from one location. So other companies that are sharing the address are causing my instance to hit this limit?
If not can anyone suggest another cause?
This discussion suggests that it is the shared origin from salesforce that is messing it up.
This only makes sense though if you are doing the geocode lookup from the server and not from a client. If you would do it fromt the client it would use the ip from the client and you are dealing with the local clients lookup limits (see below).
If you are doing it on the server you might also have to check if you are actually doing something that is legal and not breaking the ToS from google. In this discussion you will get some background on that and also a solution if you need to fix this on the server (buy a licence)
To be complete the G_GEO_TOO_MANY_QUERIES can mean one of 2 things:
You exceeded the daily limit (too many in a day)
You exceeded the speed limit (too many request is too short period)
Google has not specified an exact limit as far as I know but they don't seem to enjoy automated lookups. If you look at various libraries and plugins you'll see that all of them force a delay between each request and often they add a little randomness to the delay. You could experiment with this if it makes any difference
Did this end up working for you? we're hitting a server-side 620 and all configuration looks a.o.k... we have a premier license and upgraded to 250k requests per day.
Client has a dating site and would like to have a popup (either a nice javascript overlay or a new browser window popup. we're flexible.) displayed to users when another user is visiting their page.
I'm familiar with push technology and Comet but it's quite challenging to implement this and may place serious strain on a server with over 100,000 unique visitors per day.
I'm wondering if there is a way of faking this, perhaps by not being accurate to the second. I can't really think of any way.
This is a classic LAMP environment.
Anyone?
EDIT: what about this: placing an iframe on the page that refreshes every few seconds and at each page load it checks in the db if a visitor has been logged on this profile page. if so, it shows a message. the message would be visible but the background of the iframe would blend in with the background of the site and be invisible. if the message fades in and out, it would look like a JS box "popping up".
The only way to "fake" comet is via polling of some sort, which is always a possibility. An iframe, xhr, or jsonp request are all possibilities for performing said polling.
You might be better off purchasing a pre-built comet server (I'll recommend, of course, the one I helped build, WebSync for IIS/ASP.NET). If you're worried about the load, you could check out our On-Demand version where we'll host it for you.
Regardless, WebSync (or whatever other pre-packaged product you might check out) would scale to a hundred thousand users a day without much of a problem, and would potentially be more efficient than polling, since it would only hit your database when new users arrived, rather than every couple seconds; that said, if you keep the "check for new users" query simple enough, and a few seconds of delay is OK, the polling idea would be the "simpler" solution.
Check out http://en.wikipedia.org/wiki/Web_Sockets if you want to do real push. This isn't widely supported in browsers yet, but there are plenty of JavaScript and Flash libraries that provide it already.
Or a cheaper way is to record in your DB each page view.
Then when any user makes a web request, check in the DB if anybody has visited their page since their last web request.
If so, pop up your dialog.
This second way wouldn't popup anything if the user just left their browser sitting there, but if they were actively interacting with the site, it would achieve your goals very easily.
I would start with this second simpler solution, which is very easy to implement. If your client wants it more interactive, you can provide solutions and tradeoffs/costs for various options.
Gather statistics as to how many visitors that user's website gets per day, and then subdivide that, so that it's a percentage chance that the user will be told there is a user on his site (even if there actually isn't), based within the timeframe he's at the part where he can receive the popup. I think this is the closest you are going to get without having some sort of notification being sent.
You could do this to minimize server usage if you wanted push:
When a user visits a website, check and see if the person who would be getting the notification is online and capable of being notified, and if so, THEN do all the push stuff, otherwise forget it.