We have several interactive kiosks with files that run locally off of the hard drive. They are not "local" hosted, no web server involved. We have internet connectivity. Can we track user interactions with Google Tag Manager? I have read a few posts that seem to indicate it's possible, but the set up has changed dramatically since they were authored.
We have our GA and GMT setup, with the appropriate scripts embedded within the local html index file. We have set up a container, and several tags and triggers for simple tracking of page views. But there is no live data coming into my GA dashboard. I am sure I am missing steps if this is possible. Any help much appreciated.
Hoping I am headed right direction here - but still no tracking - where do I get a clientID to manually pass in? Thank you!!!
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-XXXXXXXXX-X',{
'storage':'none',
'clientId': 'XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXX'
});
</script>
Your question is about GTM, but it is much more likely that your problem is with Google Analytics. There is nothing that prevents GTM from running in a local file (unless you use a very old GTM snippet - I think before GTM switched completely to https, Google used an url without protocol, that would need to be changed), but Google Analytics will not work in a default installation if it cannot set cookies (which in a local file it can't).
At the very least you would have to set the "storage" field to "none" in your GA tag or GA settings variable, and then pass in a client id manually (in a kiosk it is rather hard to determine when a new visit starts, so maybe you could set a different client id every time users return to a home screen or something like that. Or you just live with the fact that everybody is the same user in GA).
Related
I'm developing a Google Sheets add-on. The add-on calls an API. In the API configuration, a url like https://longString-script.googleusercontent.com had to be added to the list of urls allowed to make requests from another domain.
Today, I noticed that this url changed to https://sameLongString-0lu-script.googleusercontent.com.
The url changed about 3 months after development start.
I'm wondering what makes the url to change because it also means a change in configuration in our back-end every time.
EDIT: Thanks for both your responses so far. Helped me understand better how this works but I still don't know if/when/how/why the url is going to change.
Quick update, the changing part of the url was "-1lu" for another user today (but not for me when I was testing). It's quite annoying since we can't use wildcards in the google dev console redirect uri field. Am I supposed to paste a lot of "-xlu" uris with x from 1 to like 10 so I don't have to touch this for a while?
For people coming across this now, we've also just encountered this issue while developing a Google Add-on. We've needed to add multiple origin urls to our oauth client for sign-in, following the longString-#lu-script.googleusercontent.com pattern mentioned by OP.
This is annoying as each url has to be entered separately in the authorized urls field (subdomain or wildcard matching isn't allowed). Also this is pretty fragile since it breaks if Google changes the urls they're hosting our add-on from. Furthermore I wasn't able to find any documentation from Google confirming that these are the script origins.
URLs are managed by the host in various ways. At the most basic level, when you build a web server you decide what to call it and what to call any pages on it. Google and other large content providers with farms of servers and redundant data centers and everything are going to manage it a bit differently, but for your purposes, it will be effectively the same in that ... you need to ask them since they are the hosting provider of your cloud content.
Something that MIGHT be related is that Google rolled out some changes recently dealing with the googleusercontent.com domain and picassa images (or at least was scheduled to do so.) So the google support forums will be the way to go with this question for the freshest answers since the cause of a URL change is usually going to be specific to that moment in time and not something that you necessarily need to worry about changing repeatedly. But again, they are going to need to confirm that it was something related to the recent planned changes... or not. :-)
When you find something out you can update this question in case it is of use to others. Especially, if they tell you that it wasn't a one time thing dealing with a change on their end.
This is more likely related to Changing origin in Same-origin Policy. As discussed:
A page may change its own origin with some limitations. A script can set the value of document.domain to its current domain or a superdomain of its current domain. If it sets it to a superdomain of its current domain, the shorter domain is used for subsequent origin checks.
For example, assume a script in the document at http://store.company.com/dir/other.html executes the following statement:
document.domain = "company.com";
After that statement executes, the page can pass the origin check with http://company.com/dir/page.html
So, as noted:
When using document.domain to allow a subdomain to access its parent securely, you need to set document.domain to the same value in both the parent domain and the subdomain. This is necessary even if doing so is simply setting the parent domain back to its original value. Failure to do this may result in permission errors.
I have a specific issue where I'm using WebRTC (voice and video).
I want to keep a connection/voice/video streams alive between webpages on a website. I thought I could use shared web workers to run in the background?
Any guidance would be great. I've looked at other posts but they're quite old and wondered if anyone had any, more, up-to-date information or ways I could tackle this issue?
UPDATE:
Shared Web Workers are the incorrect way of tackling this problem. Service Workers are the way forward for maintaining after the web page is terminated.
Keeping the webRTC connection alive between page loads seems like a rare use case. Normally, you start a call and remain on a single page. I guess it could make sense if you wanted to embed a customer support like webRTC widget on a site and have that widget follow a user through page navigations under a single domain.
I don't think saving/reusing the blob URL will allow you to reconnect on a page reload for security issues/hijacking potential.
There is the IceRestart constraint which might help. Apparently you can save the SDP info to local storage, reuse the negotiated SDP, then call an IceRestart to quickly reconnect.
As described in section 3, the nominated ICE candidate pair is
exchanged during an SDP offer/answer procedure, which is maintained
by the JavaScript. The JavaScript can save the SDP information on
the application server or in browser local storage. When a page
reload has happened, a new JavaScript will be reloaded, which will
create a new PeerConnection and retrieve the saved SDP information
including the previous nominated candidate pair. Then the JavaScript
can request the previous resource by sending a setLocalDescription(),
which includes the saved SDP information. Instead of restart an ICE
procedure without additional action hints, the new JavaScript SHALL
send an updateIce() which indicates that it has happended because of
a page reload. If the ICE agent then can allocate the previous
resource for the new JavaScript, it will use the previous nominated
candidate pair for the first connectivity check, and if it succeeds
the ICE agent will keep it marked as selected. The ICE agent can now
send media using this candidate pair, even if it is running in
Regular Nomination mode.
https://bugs.chromium.org/p/webrtc/issues/detail?id=979
https://datatracker.ietf.org/doc/html/draft-li-rtcweb-ice-page-reload-02
I'm having some issues with Google Analytics URL parameters. Prviously I've built URLs with the Google Analytics URL Builder. these have enabled me to track where visitors to my site have been coming from, how successful various marketing campaigns have been etc.
Recently, I've started using another tag in the URL, one which has nothing to do with Google Analytics, but acts to alter the telephone number on my site when the visitor arrives on it. For example, I'll add &ctcc=adwords onto the end of my tracking URL, and a specified phone number will appear on my site when the user comes through so I can track how many calls my adwords spend has generated.
However, when I've been using this ctcc code, Google Analytics no longer seems to be tracking the traffic numbers to my site :(
Any idea how I can incorporate the two parameters into the URl, and ensure that they both work as expected?
Thanks in advance
It looks like this is a problem with how your server is redirecting traffic with a ctcc query parameter. Look at the following request and its response headers:
So the ctcc parameter is used in some server side tracking (as best as I can tell), and the server is set up to redirect & strip ctcc whenever it gets a request with ctcc. Not being familiar with the system in use, I can't provide details, but you need to reconfigure the redirects to stop changing & into ;. It's the replacement of ampersands with semicolons that is messing up your GA data.
I'm trying to build a "native web app" using HTML + JS on iOS. As you may know you can add such an application to the homescreen and it will more or less look just like a normal native app.
However if I quit such an app and reopen it again it reloads the whole page again. This also happens when switching to such an application from another over the multitasking bar.
Is this expected behaviour or is there a way to stop the device from doing this?
As an example you can add the jqTouch-Demos from here to your homescreen and test it: http://jqtouch.com/preview/demos/main/
You could save the state of your app in localStorage. On restart, check to see if the state is running, then restore the app to where it last was.
Same problem here.
Anyway, if you don't want to reinvent the wheel you can use a tool like PhoneGap (http://www.phonegap.com/). Native web application wrapper with built in access to a number of native features.
Also, you store the application locally (fast, secure) and you can of course charge for it ;)
It's under BSD or MIT license.
Update: as this answer is receiving downvotes, I added this explanation.
Your problem might not be the actual reload, but the fact that Mobile Safari treats your user's cache and cookies differently when your web app is opened through the browser, than when it's 'installed' as a web app to the home screen. Although the solutions proposed here that use localStorage will work, they're a lot of work for client-side logic that can be avoided if your server is already responsible for persisting the session state of your user. The 30-second solution is to simply explicitly set the session cookie to have a longer lifetime.
This allows you to keep the state intact even between device reboots, so even though it doesn't technically stop the web app from being reloaded when launched from the home screen, it is an easy way to restore the state for the user without him/her noticing the reload - which in many cases I suspect is the real problem.
For a more elaborate discussion of this strategy and code examples, take a look at these questions and my answers there:
Maintain PHP Session in web app on iPhone
iPhone "Bookmark to Homescreen" removes cookies and session?
You might want to look at using cache-manifest to prevent it loading the files.
Matt Might has a good writeup here:
http://matt.might.net/articles/how-to-native-iphone-ipad-apps-in-javascript/
Basically you change the html tag to this
<html manifest="cache.manifest">
and write a cache.manifest file on the server which specifies which files should be kept in the device cache and which should be reloaded dynamically from the network.
CACHE MANIFEST
local1.file
local2.file
NETWORK:
network1.php
network2.cgi
You also need to make sure your web server serves up .manifest files with the MIME type text/manifest, or else this won't work. If you're using apache, put the following in your .htaccess file:
AddType text/cache-manifest .manifest
I'm seeking for solution how to isolate widget included by partial to main site. Issue appear when user access site with https. Ie 6,7 shows security confirmation dialog (part of website resources are not in secure zone).
First of all I download twitter widget on our side, also I download all CSS and pictures. Then I patched widget JS to point onto downloaded resources. But still has not luck with security warning :( I guess the reason of this issue is AJAX request to twitter, but there is no idea how to sole it. (Just to create some kind of proxy on our side).
Thank you for attention.
You just need to host the .js file on your server, and link to that. That is all.
The script auto detects SSL and will make requests to https://twitter-widgets.s3.amazonaws.com/ instead of http//widgets.twimg.com/ dynamically depending on your scenario.
Hope that helps!
geedubb
I got the Twitter Widget to work over HTTPS (SSL) by doing the following:
Save every image, css, and javescript file on my local webserver
Changed every "http" to "https" in the javascript AND in the css
The last piece was tricky. https://twitter.com/statuses/user_timeline.json brings back data that already includes "http"; namely avatars and the profile image. So, I found about four places in widjet.js that used the user_timeline.json data. I hardcoded an image url where ever that "http" data was used. Searching "src" will located all of those places.
It's an ugly fix, but it worked.
You can use a sniffer like HttpWatch to debug this--watch the requests going by and see which ones start with http instead of https. It may be possible to just change the urls you use to point to https://twitter.com, not sure about how your widget works.
thanks Keshar, worked for me. I came to the same conclusion that all http requests had to be https to prevent the IE security warning and also display the twitter feed. I used the live HTTP headers firefox plugin which helps for showing any non-secure http requests, such as the JSON requests.
Jon
If you look through the script there are calls to a https site. If you simply replace the protocol/domain with
https://twitter-widgets.s3.amazonaws.com/
instead of
http//widgets.twimg.com/
it works and you don't have to do anything else.