We currently track users on an Android-based project using UTM tracking. I've heard reports that not all users are being tracked (i.e. 20 users download the app using the UTM link, but we can only find records of 15 in the data).
I was curious as to whether anyone else has experienced something similar? It feels like the most likely scenario is that the users are typing in the link wrong or something similar, but I wanted to check I'm not missing anything obvious before jumping to conclusions.
The links we are using look like this:
https://play.google.com/store/apps/details?id=org.sample.sample&referrer=utm_source%3DXXX%26utm_medium%3DXXX
And the code snippet in the AndroidManifest.xml file looks like this:
<application>
<!-- Used for Google Play Store Campaign Measurement-->
<receiver android:name="com.google.android.gms.analytics.CampaignTrackingReceiver"
android:enabled="true"
android:exported="true">
<intent-filter>
<action android:name="com.android.vending.INSTALL_REFERRER" />
</intent-filter>
</receiver>
<service android:name="com.google.android.gms.analytics.CampaignTrackingService"
android:enabled="true"
android:exported="false" />
</application>
Auto-answering as I found the response. Essentially, there are problems with UTM links when users access them via a web browser rather than via the Play Store. Using link shorteners like bit.ly force a web browser experience and hence many users are untracked. UTM parameters in data show up as "not set", rather than what the actual original parameter was.
Wondering how many apps have incorrect tracking as a result of this, could be a lot...
Related
I'm developing an Outlook add-in and I need to store a base URL that will be called to perform an action. I need that this URL can be configurable.
My idea was to save that URL in the manifest.xml but I can't find a way for the adding to get it. I can't find anything related in the Office object (Office.js).
Example:
<bt:Urls>
<bt:Url id="Commands.Url" DefaultValue="https://localhost:3000/commands.html"/>
<bt:Url id="Taskpane.Url" DefaultValue="https://localhost:3000/taskpane.html"/>
<bt:Url id="Base.Url" DefaultValue="https://my-base.net/" /> <---- this
</bt:Urls>
Maybe this is not the right way...
You can specify the default URL in the add-in manifest and save the new data in the local storage of your add-in. See Persisting add-in state and settings for more information.
But there is no trivial way at present for an Office Add-in to read its own manifest. However, you can load it in JS if you know the exact place where it will be hosted. It is just a file on the web server.
So, I'd suggest avoiding the manifest file for data settings nowadays. It acts like your add-in's metadata. Instead, keep the strings hardcoded in the add-in and store in the settings or local storage the new value.
I am posting this as a question and answer for anyone else that has this issue as it was an absolute PITA to debug.
We have a taskpane add-in for Word that has a login page using cookies to store the session state. This works completely fine in everything except Word Web in Internet Explorer 11 on Windows 7.
By using Fiddler we can see that our cookies were getting set and everything is fine, even the session cookie stays the same (this is another issue altogether), but for whatever reason the .AspNet.ApplicationCookie is never getting sent back with the request for the HTML page - but it is getting sent back for the request for the JavaScript. WTF.
See the answer to this post: Cookie blocked/not saved in IFRAME in Internet Explorer
The issue has to do with the fact that in Word Web the taskpane is in an IFRAME. It has something to do with P3P policies - which as far as we can tell don't get used by anything else.
Anyway here are the important bits from that answer:
I've spend a large part of my day looking into this P3P thing and I feel the need to share what I've found out.
I've noticed that the P3P concept is very outdated and seems only to be really used/enforced by Internet Explorer (IE).
The simplest explanation is: IE wants you to define a P3P header if you are using cookies.
...and the solution...
In short - to keep IE happy - add the following line to your PHP code (Other languages should look similar)
header('P3P: CP="Potato"');
Problem solved, and IE is happy with this potato.
So basically you need to add this HTTP Header to all responses to get IE to play ball.
If you are using IIS to host your website, add this to the web.config:
<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="P3P" value="CP='Potato'" />
</customHeaders>
</httpProtocol>
<system.webServer>
<configuration>
I'm creating a website that I want people to share and when they share a link I want them to see an image that I curate. How can I set that up?
The site relies heavily on javascript and background images... is that maybe why nothing is turning up automatically?
The main places this would be nice are: Facebook, Slack, Pinterest, ... places like that.
In order to generate nice preview links you need to do some additional work.
To control how your link would be viewed you would need to set up special meta tags. For example,Facebook uses Open Graph tags:
<meta property="og:image"
content="http://graphics.myfavnews.com/images/logo-100x100.jpg" />
https://developers.facebook.com/docs/sharing/best-practices
I have created a directory based site in ASP.NET MVC3 which when you navigate through the site you get to a page like http://server/domains/details/mydomain.coop.
The rest of the site works fine however when you go to this url you get a page not found error. I have put logging in to the controllers and the action in the controller is not fired. It works fine on my local machine (VS2010 / W7) but when it it is put on to the live servers (MS 2003 server IIS6) it breaks.
If the url does not contain the "." in the final domain name part (the bit that is passed through to the optional parm "id" on the default route then it all works.
Does anybody have any ideas what I can do as I really want the "." in the id part for SEO
Many thanks
Jonathan
You could use a - to make your url like http://server/domains/details/mydomain-coop. I'm not sure of the SEO implications, but I can't imagine it being better or worse than a .
Periods and other punctuation have a very specific meaning in URLs - in this case, it indicates a file extension, which is used to determine which IIS modules and filters (I always get these two confused) are activated to handle a request.
You should really think twice about formatting your URLs this way; non-standard uses like this are not your friend.
Conjecture:
It's possible that a search engine may use the part after the . to determine MIME type, and either ding your score if it doesn't match the actual page content, or it could ignore the link entirely. Note that, for instance, Google indexes images and pages differently based on both file extension and MIME type (though someone more versed in the dark magic of Google's internals may chime in with a better/more accurate explanation.)
Here's a nice post on getting ASP.NET to ignore certain file extensions,
See also this SO question about a similar issue (registering custom file extensions - in this case, .coop)
The important web.config entries from the second link are:
<httpHandlers>
...
<add verb="*" path="*.mycustomextension"> type="System.Web.UI.PageHandlerFactory"/>
<compilation >
<buildProviders>
<add extension=".mycustomextension" type="System.Web.Compilation.PageBuildProvider" />
</buildProviders>
I haven't had time to test this, but hopefully it'll get you going in the right direction.
I have a Facebook Connect application (IFrame, external website).
When i post to the user's wall using the Old JavaScript API (FB.Connect.streamPublish), im specifying action links, as many people do.
Here's the JSON for my action link:
[{ 'text':'Do something on my site', 'href':'http://www.mysite.com/somerestfulpath' }]
Now, we use URL Rewriting on my website, so the URL's are all nice and RESTful (i.e. no .ASPX).
Now, for some reason, the link that gets rendered out on the user's wall is:
http://www.mysite.com/somerestfulpath?ref=nf
Of course this is 404'ing.
It seems to be this way for all Facebook apps (not just mine), that for any custom action link, Facebook will automatically append ref=nf to the URL.
For other parts of the post (links, images, etc), they don't do this.
So the only think i can do is change the link to the un-RESTful URL:
http://www.mysite.com/pages/actualpagewhichidontwantuserstosee.aspx
Then it will render:
http://www.mysite.com/pages/actualpagewhichidontwantuserstosee.aspx?ref=nr
Which works.
But WTF, why are they doing this? And can they not give those applications with URL rewriting an option for them not to supply this?
I was hoping to keep the URL's all clean and rewritten.
EDIT:
My bad, the regex rules on the URL rewriter wasnt correct. Burn.
PEBKAC (Problem Exists Between Keyboard And Chair).
My regex rules for this particular page was not foolproof enough.
For anyone that cares, this is what i had:
<rewrite url="^~/somepage$" to="~/Pages/SomePage.aspx" processing="stop" />
This is what i changed it to:
<rewrite url="^~/somepage(.*)" to="~/Pages/SomePage.aspx" processing="stop" />
Also, i was wondering why in Fiddler i was getting all these 404 errors coming from Facebook.
Turns out i was registering the 'xd_receiver.htm' wrong:
FB.Init('myapikey', 'xd_receiver.htm')
So on ALL pages, Facebook was looking for the file relative to the path.
It needed to be:
FB.Init('myapikey', '/xd_receiver.htm')
Never forget the '/'. =)