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]
Just wondering why there isn't that many ide that can edit native code at runtime.
Visual Studio is the only one that can do it?
gdb can "compile and inject code", but it only executes a single line of code, doesn't seem like it modifies anything.
Found this https://www.google.com/patents/WO2015200235A1?cl=en , but not sure where can I get the whole patent, it's just ocr without any graphic.
I need to know if that technique of starting all functions with 6 nop is patented, that's all I care. It's pretty old by now. I plan on developing a language, if that matters.
To get a full answer you would need to contact a patent attorney, patent search company or engage with an examiner at a particular patent office.
For the patent you found above, you can obtain more complete information, including drawings etc from WIPO PATENTSCOPE here.
The preliminary search report from WIPO indicates that claims 1,2 7, 9 10 and 15 are insufficiently novel, and claims 1-15 do not constitute an inventive step on the basis of obviousness.
The WIPO Application has entered into national phase under application EP15735802 in Europe, and the website shows two citations, one patent and one NPL (non-patent literature). I can't post the link because I am new to stack overflow and can only post two links, but you can use the 'national phase' tab of the link above to go direct to the European Patent Office website.
You can search Esp#cenet using keywords to see if there are other inventions out there which are close to your idea.
I already have Google-Authenticator on my iPhone - yay!
I want to have it on my iPad too (which I don't carry with me daily). I cannot see how to set that up in Google's online advice.
I don't want SMS as second factor because it is not in any way safe in 2017. SMS as a second factor is less secure than a strong password alone.
Go to https://myaccount.google.com/security/signinoptions/two-step-verification on your Mac/PC.
Generate, and perhaps print off some "Backup Codes"
Log out and log in to test one of those ten backup codes (perhaps a different browser so that login requires the second factor).
On your iPhone, delete the line in Google-Authenticator for the existing Google-Accounts setup.
Click on the pencil icon, to the right of the "Authenticator app (Default)" you already have.
Click "Change Phone", and show the new QR code the screen. In both iPhone and iPad scan the QR code. Yes, the same QR code twice. Note now that the one-time-passcode is the same on both. Do both quickly as there is only a certain amount of time to complete this in.
Note: I could not find a way of deleting the backup codes. I mean I can shred the printout, but can't see how to get the list of second-factors in Google-Accounts to drop the backup codes.
I'm getting some very strange behavior in DTM. When our page loads (from a local instance of the website) we get the expected call going out with the proper dev report suite. When a custom link call is made from that page, for some reason DTM sends it with a production report suite. If I look in Adobe Analytics for the custom link name reported under the prod RSI, it does not show up in there.
Any ideas on what is going on and how I can fix this issue?
This is my shot in the dark based on what you have said, and it is based on the assumption that your statements are true (e.g. you aren't seeing pink elephants, that the request was indeed showing your prod rsid in the proper portion of the request url, that you did in fact check your prod rsid after an acceptable amount of time has past, no segment or other filter shenanigans, etc..: in short, that you do know how to accurately perform the basic QA song and dance).
Under that assumption, the below is a scenario that can plausibly reproduce what you are describing. I could be partially right or totally off for your specific situation, but there's really no way for me to know for sure without having access to your DTM instance.
The Scenario
Long story short is it sounds like you have a blend of custom code and DTM automatic settings enabled, and DTM is overriding and/or not caring about your custom code for link tracking.
More specifically, it sounds to me like you have AA implemented as a tool in DTM, and in the config settings, you have your production and staging rsids specified in the text fields.
Then in the General section, you either do NOT have values specified for Tracking Server and Tracking Server Secure, or else they are set to the wrong values.
Then, in the Library Management section, you have either selected "Managed by Adobe" in which case DTM takes care of the library, or else you have selected "Custom" and you are adding the library yourself AND you have NOT checked "Set report suites using custom code below".
Then, somewhere in DTM (e.g. the Library Management > Custom code box, or Customize Page Code codebox) you have code that pops rsid stuff (e.g. s.account, s_account, dynamicAccountList stuff), and possibly also trackingServer and trackingServerSecure.
Finally, you (like most other people, because DTM's double script include for staging vs. prod is.. dumb) just use the prod script include on your page, and either use the debug/staging mode or rely on whatever rsid routing logic you've setup to route to dev.
So.. when the page is first loaded, DTM loads the AA library and it sets variables and stuff based on what you specified in the tool config. During this time, it is also popping any custom code blocks you have in the tool config, which may or may not override what you have specified in the tool config fields, depending on what you enabled. Then after that, it pops stuff you have in page load rules (if any), etc..
But then comes the link click.. As I have mentioned in other posts on SO, DTM has this caveat (IMO bug) about how it references the AA object after the initial page load/AA request: basically, it doesn't. Instead, it makes use of internal methods (the main one being a .getS() method) to create a new instance of the AA object, based on whatever things you have configured in the tool config section. Well here's the rub.. it does NOT account for or execute any custom coding you have done in code boxes in the tool config section.
So that basically happens whenever an event based or direct call rule is triggered, and it effectively screws you. Why does DTM do this? I do not know. IMO Adobe needs to change this feature caveat bug. Either they should refactor DTM to execute the code boxes, OR they could, you know.. just reference the original AA object created, like any normal script would do..
But in any case..
So for example, my theory here is that page loads fine, points to dev rsid based on your setup. But then you click a link and an event triggers, and DTM makes a new AA object not caring about your custom code, so all it has to go on is what you have in the tool's config fields.
Since DTM doesn't actually have any rules around the prod vs. dev rsids you specify in those fields (you have to write custom code in the custom code boxes - that DTM ignores!), it just pops the prod rsid, because that's the script include you have on your page.
Then as far as not seeing the data actually show up in your prod rsid: again, since DTM ignores what you set in your custom code boxes, it's defaulting to what is specified in the trackingServer fields in the tool config, and my assumption here is they are either blank or wrong (you should be able to look at the request url to adobe to verify this). This theory is because you said the prod rsid is right, and you see a request being made. So the next culprit would be wrong tracking server specified.
So, that is my theory of what's going on. Maybe it's all right, maybe it's some right, hopefully it may point you in the right direction at least.
Edit:
If you can confirm that this is indeed how you have things setup, then you will naturally ask "Okay, well what do I do about that?". As I have said in a lot of my other SO answers.. basically, your only option is to uncheck all the settings that make DTM automate AA, and in all your rules, keep the AA section disabled and whatever AA vars you wanna set, set them yourself and make the s.t() or s.tl() call yourself in a 3rd party script code box, so that it continues to reference and pop based off the originally instantiated AA object.
Update
Based on your comments below, okay so yeah.. that sounds like what I described, and accounts for prod rsid popping. As for data not showing up in report.. so if you are certain tracking server is set correct (the request url looks good) then this isn't a DTM issue. Here are some other explanations for why the data wouldn't show up:
Are you sure the request is being sent to your prod rsid? I don't know what you are looking at to verify this, but this is where you should be looking: In the request URL to AA: "http://[trackingServer value]/b/ss/[s.account value]/1..."
Click request isn't making it to Omniture. Verify in a packet sniffer that the request is actually made and that you are getting a 200 OK or NS_Binding_Aborted response.
You aren't waiting long enough to check for the data. Even basic hit data and looking at "real time" reports takes a little bit of time to show up.
You have a segment/filter active that's not jiving with the data you are trying to look at. Make sure that you don't have anything applied. Or, if you are using those things to find your data (and aren't seeing it), ensure that you are correctly applying it.
You recently created the rsid and the "go live" date hasn't passed yet. Data will not show up in the report suite until up to 24 hours after the specified "go live" date.
You have a vista rule in place that's affecting data showing up. Some companies have a vista rule in place for a number of reasons and there are a million ways it could affect data (e.g. routing to a different report suite). For shits and grins, check your dev (or other rsids) to see if your data showed up there. Even if that doesn't make sense, at least it's a step forward.
You have a bots / ip exclusion rule in place that's catching data from your location.
The data sent in from the link click isn't relevant to the report. For example, maybe you are looking at e.g. prop10 report and prop10 isn't actually sent in the click request.
I know a lot of these are basic things to check, and no doubt you've checked, but check again. Have someone else check for you to be sure. I'm not questioning g your abilities here, but even the best of coders forget to cross their t's and dot their i's sometimes, and manage to miss obvious things. If you are sure about all of these then contact Adobe ClientCare because I really can't think of anything else that wouldn't involve an issue with Adobe's backend.
I ran into a similar problem with my implementation. Essentially what I did was set the s.account variable directly inside the doPlugins, so it would be set on all tracking calls. I wrote specifics here also: DTM Tracking Account
Questions
When sending an AppRequest, my friends list that comes up on iOS always has 48 users in it even when I have 300+ friends. Is there a way to change this limit for high-end devices that have plenty of memory?
How does FB decide which 48 friends to show in the AppRequest dialog? It doesn't appear to be my first 48 friends alphabetically
The "Title" parameter of the AppRequest call doesn't get used. Even in the InteractiveConsole, I set the title to "Invite Friends" and the title always says "App Requests". Is this just broken or am I confused?
Edit: I know there is a maxRecipients param but my understanding is that only determines how many total can be SENT at once, not how many friends display. I have the maxRecipients set at 500 and it still only shows 48 friends in the list.
Info
Unity version: 4.3.0f4
FB SDK version: 4.3.4
FB Build version: 131022.2bb3e6026790434
Right now there's no way to change the number of users who come up in that selector. They're chosen according to Facebook's estimate of how likely they are to be interested in, and interact with, an apprequest.
I believe that the issue with the title may be a bug. I'm investigating that now; could you please file a bug in the FB developer bug tool, and post the URL here, to help with that?