https://apps.microsoft.com/store/detail/name/ID
Linking to my app product page gives "Not Available for bots to index"
What is the proper syntax to place a href link to the product so that users online can view it as html?
I don't have a final solution, just a workaround.
We've been seeing the same issue with our own app for the past few days and we've started seeing reports of people encountering this with all kinds of apps, including even Microsoft's own AppInstaller. It seems to be a server-side rate-limiting/caching issue at Microsoft as changing anything in the URL fixes the problem temporarily -- only to get back to the same issue a few hours later. We also found that VPN-ing to some locations (mostly to the US) helped as well, and this throttling seems to be specific to an app & an availability region (when it got blocked, it blocked across all Europe, but not in US for example). It seems to come & go as we have not seen a big drop in new install counts.
As a temporary solution we ended up adding a random string to the end of the URL. We used GCLID as we found it to be the least offensive way -- it could just as well be a legitimate tracking ID we pass over. So now the URL we link to looks like this:
https://apps.microsoft.com/store/detail/[APPNAME]/[APPID]?gclid=f-3579a28842a7bcac7ba630d698829e9b
Where the "f-xxxx" value is generated using the md5() of the timestamp -- but it could be any ever-changing value, even a random number.
We've reached out to our MS contact about this but we haven't heard back yet.
I encountered the same issue half an hour ago, but it seems recovered now.
If you own an app, you can confirm Product identity in Partner Center:
You can share the direct link and Store ID to help customers find your app in the Store:
URL: https://www.microsoft.com/store/apps/*12CharsAppId*
Store ID: 12CharsAppId
Store protocol link: ms-windows-store://pdp/?productid=12CharsAppId
The above address would be recommended but the apps.microsoft.com URL should also work.
I work on apps.microsoft.com. I can confirm that there was an issue on our end that appeared on August 23. This issue has been resolved.
And the proper link, of course, is this:
https://apps.microsoft.com/store/detail/[your product id here]
Related
I am trying to get in touch with LinkedIn support for the past month now, unfortunately I had no luck getting to the dev team through the account management.
We are using a reporting tool to pull LinkedIn campaign data via their API. We would like to pull Campaign Names which doesn't seem to be possible at the moment referencing https://developer.linkedin.com/docs/ref/v2/ads/adcampaigns#get
However, is there any kind of way to retrieve the Campaign Names (ID is making it really hard for us to identify campaigns on the fly)? It seems like such a basic request, I find it hard to believe LinkedIn has no way of doing this.
Thanks in advance!!
A little further down that page you referenced is a section called "FINDER" with this:
https://api.linkedin.com/v2/adCampaignsV2?q=statuses&statuses=ACTIVE
Options are ACTIVE, PAUSED, ARCHIVED, COMPLETED, OR CANCELLED
You will get the "name":"MY_CAMPAIGN_NAME" field there. That's the only place I've found it so far.
We have two nopcommerce shops running on pretty much the same code. Both of those have GA handled through GTM with more or less the same code, however for some reason on one of those two shops all visits to the index page end up being registered incorrectly.
There are two index pages:
http://domain.co.uk/en/
http://domain.co.uk/pl/
Visiting http://domain.co.uk redirects to one of the above. Anyway when I visit either of those two, analytics adds the domain name at the end for some reason, so if I visit http://domain.co.uk/en/ GA registers http://domain.co.uk/en/domain.co.uk.
I tried adding canonical (with the actual address) to the index page, but it changed nothing. Note this problem only happens on the index page, other pages are registered correctly in GA. Anyone got an idea what could possibly make analytics save those addresses incorrectly?
It's hard to reproduce this error, the only way is via "RequestURI" filter. Is there any chance you have such, it could be the reason for this.
Barnettt's suggestion made me (and my boss) look through the Analitics' settings some more and I think I figured it out. Someone set default page (view settings) to domain.co.uk. The value is obviously incorrect, but more interesting is the fact that it was probably there from the start, yet the incorrect page started getting registered only a few months ago.
Been trying to get this working for a few weeks now. Any help is greatly appreciated.
I have recently upgraded to Universal Analytics and managed to successfully set up cross domain tracking with the autoLinker but I can't get my Analytics Experiment to pass the _ga variable when redirecting the user to a domain part of the experiment.
Setup
Both domains have two trackers, one (t0) which they share [UA-xxxxxxx-5] and one (domainUniqueTracker) which logs to a trackingId unique for that specific domain ([UA-xxxxxxx-1] for main domain and [UA-xxxxxxx-14] for new experimental domain).
Linker is loaded on t0 to enable sharing across domains.
Linker is loaded with an array of domains, including the domain I'm trying to send traffic to via the experiment.
Experiment is created on shared trackingId [UA-xxxxxxx-5].
Context
My company has a product called LIME Pro where we until now have had info about on our company web page. Now, as an experiment we have created a one-page about the system on a separate domain, and they want to see which page (old or new) attracts most leads.
Old product page within company web page (experiment code installed there)
http://www.lundalogik.se/crm-system/lime-pro/
New product page on separate domain (shares trackingId with main domain on tracker t0)
http://www.lime-pro.se
Problem
If I visit www.lundalogik.se and from there click on a normal link to the new, external site (normal anchor link on dummy-page lundalogik.se/experiment/) the clientId is successfully passed along in the URL and the tracker at the external site recognises this and starts using the clientId.
But if I browse to the page where the experiment code is installed, I am redirected to the external site without the clientId being passed along, so the tracker at the external site generates a new clientId.
Thanks and sorry about long post, wanted to explain in as much detail as I could.
The various linker functions in UA add _ga to outgoing links (form, frames etc.). Since the redirect happens in the experiment javascript the client id cannot be added to the url (which in a way seems to be an oversight on Googles part - it seems they did not anticipate your use case, i.e. content experiments across domains).
I have a few untested ideas to contribute, maybe you can build a solution on top of one of them.
1) Before the experiment code fires push the client id to window.document.location.hash. At least in Chrome this does no cause a reload (as far as I can tell from looking at the network tab). Since the hash is now a part of the url it should be sent along when the redirect fires. Then you need a script on the receiving page that checks the hash for a clientID and passes it to analytics if present.
2) Basically the same, only this time with the pushState method (https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Manipulating_the_browser_history) which should allow you to provide the query parameter without reload.
3) Make the variation page a page within your main domain. Instead of any content put a javascscript there that reads the clientId from the cookie and redirects to the other domain
4) Same as 3, only serverside (don't forget to include the content experiment parameter in the redirect)
As I've said this is basically thinking aloud but it might provide clues toward a solution.
My apologies for only having half an answer but I got orders from above to drop this before I got it fully working. Hopefully it will still be somewhat helpful for someone looking to do the same.
If you do get the receiving part done, please post your code here and I'll update this answer/reward you with the answer.
OK here goes nothing..
The sending side works and adds the clientId to the hash and it is successfully transfered when the experiment does a cross domain redirect.
PAGE WITH EXPERIMENT CODE
Execute this before you run the experiment code.
var z, y, x = document.cookie.split("; ");
for (var i = 0; i < x.length; i++) {
y=x[i].split("=");
if (y[0] == "_ga") window.location.hash = y[1];
}
PAGE ON CROSS DOMAIN
Here is where I never got to before receiving my orders to drop this. But you would do something like:
checking window.location.hash and if it contains a clientId (window.location.hash.substr(0,3) == "#GA")
check for existing cookie
2.1. (exists) split cookie by "; ", find "_ga" and replace it's value with above hash (remove "#" first)
2.2. (doesnt exist) create a new cookie at domain level and set "_ga=(hash-value)"
initiate google analytics tracker which would assume the visitor already had accessed the page before and accept the client-id from the cookie
live long and prosper
So, sorry again for an answer is only partially complete but hopefully someone will benefit from this.
Or at least not assume they are mad like I did when I couldn't get it working :).
If the community would like I will of course remove the "accepted answer" if this is considered bad practice (this is only my second post ever to the SO network).
I am playing with Google Analytics API and found that when I get the web property list, I have a defaultProfileId very useful. It can just help me pass the queryProfiles call, to save one request and make the whole app works faster.
But I noticed that some web properties just don't have the defaultProfileId thing.
Just for the information, most of the situations happens to a tracking ID like UA-XXXX-1.
Any tips?
Thanks!
You are correct webProperty does not always return a defaultProfileId. I was also unable to find any information on the Web Properties page as to how the API decides what a Default Profile Id is. I submitted a bug report for it, with the Analytics dev team you can find it at: defaultProfileId - not always sent with a WebProperty. Lets hope they come with a response you are correct this is a very useful feature.
Yes you are probably going to have to query the profiles every time to get the correct profile you are after.
I just found this:
https://www.googleapis.com/analytics/v3/management/accounts/~all/webproperties/~all/profiles?oauth_token={Token}
There should be away of working that to make one request for accounts, one to get all the Web Properties , then one to get all the Profiles.
We have some third parties that are sending us traffic and have asked us to put a tracking pixel on the confirmation page so they can track through the sales.
We are currently using Google analytics for our own usage.
Google will remember the original referral through cookies. This may be a good or bad thing. If someone purchases through company B's link but they had originally found our site through company A - then company A still gets the 'referal'. That doesn't seem fair, but it seems to be the way google analytics works:
For example, if this is the user's
first visit to your site, the tracking
code will add the campaign tracking
information to the cookie. If the user
previously found and visited your
site, the tracking code increments the
session counter in the cookie.
Regardless of how many sessions or how
much time has passed, Google Analytics
"remembers" the original referral.
This gives Analytics true
multi-session tracking capability.
Currently we only have one tracking pixel on our 'receipt page' from a company that we're not even doing business with. Having a second company ask me for us to add one makes me thing 'wait a minute - we're going to suddenly be inundated with these things!'. Plus it means someone can look at the source and see all the people we do business with.
This isn't Oprah - you cant ALL have tracking pixels. Right ?
How should we manage sales from multiple traffic sources in the most honest way for both sides - especially if they already have a system set up that they insist on using?
Here's how I solved the problem at our company: we gave our partners a URL that has a parameter in the query string. This parameter triggers a cookie. On the "goal"/confirmation page (where the tracking pixel is usually inserted), we insert some logic to see if the cookie value is correlated with a one of our recognized partners (chained if-else or switch statement). If a match is found, then the tracking pixel is displayed.
Even though you asked this question a while ago, I hope that this still helps you or someone else with the same problem!