I have multiple products on Amazon that are being purchased. What I would like to find out is how the buyer found the item on Amazon. Did the buyer search on Amazon? Did the buyer follow a link from a Facebook Post or Tweet?
Is there anyway to retrieve this or any similar information? I don't care if it's from Reports, the MWS API, or anywhere else.
I found an article from 2012 that claims this functionality wasn't available at that time. But perhaps things have changed.
http://www.forbes.com/sites/suwcharmananderson/2012/01/11/amazon-should-give-self-publishers-more-data/#5b1bf155368e
Amazon has no control over how someone may access a particular page. This is more or less inherent in the nature of the internet, where from any location, you can link directly to a website. Furthermore, your browser doesn't 'pass forward' so to speak your browsing history to the Amazon, so it would have no data to record in this regard.
There are certainly methods of tracking this, for instance, if you have a special link that is ONLY posted on facebook, and the link simply records the click, and forwards you to the actual listing, but that would require controlled dissemination of website links, which is basically impossible.
So.. to answer your question, it is theoretically possible, and exceedingly improbably that this information is available.
Related
I want to know what keywords brings users to our website. The result should be such that, every time a user clicks on a link of the company's website, the page URL, timestamp and keywords entered in search are recorded.
I'm not really much of a coder, but I do understand the basics of Google Tag Manager. So I'd appreciate some solutions that can allow me to implement this in GTM's interface itself.
Thanks!
You don't track them. Well, that is unless you can deploy your GTM on Google's search result pages. Which you're extremely unlikely to be able to do.
HTTPS prevents query parameters to get populated for referrers, which is what the core reason for it is.
You still can, technically, track Google search keywords for the extremely rare users who manage to use Google via http, but again, no need to do anything in GTM. GA will automatically track it with its legacy keyword tracking.
Finally, you can use Google Search Console where Google reports what keywords were used to get to your site. That information, however, is so heavily sampled that it's just not joinable to any of the GA data. It is possible, however, to join GSC with GA, but that will only lead to GA having a separate report from GSC and that's it. No real data joins.
I was thinking of opening an Amazon affiliate account soon.
However, when looking up how well kept the privacy is with these links, it's pretty strange how I find very little to no information.
If anybody here knows how Amazon affiliate links work, could you tell me if it'd be possible to decrypt the affiliate links (or through some other means) somehow and access account information?
If someone really wanted to, would they be able to get any information about me through my Amazon affiliate links?
Thank you.
Well, firstly you should use an Amazon Business account for this, so you would already have your data separated out from truly private information.
But the core of this question is if Amazon is going to expose or fail to secure your data. I personally don't feel that Amazon is going to be the weak point in securing your personal information.
From just a user perspective without malicious intent, you really don't get any information about the affiliate link you're using.
With a storefront, you give out some more information, but still only what you choose and no addresses or phone numbers, or any PII like that.
As a Developer, I don't know of nor could I find any endpoints that would let me look at other affiliates' information, and I am sure there are none
I understand how to extract order information from the MWS get_report function but nothing related to the business or the advertisement reports.
My intention is to periodically extract amazon ad related information(clicks,CTR...) and also business reports( sessions, buy box...). Is this even possible?
Anything you'd be able to get would be listed here as a report type enumeration. Out of the things you've asked about, the only possibility that I'm aware of is buy box information. There is some of that in the Products API but the best place is to subscribe to the AnyOfferChangedNotification which gives real time pricing updates with buy box information.
My primary question is: Can connected apps add relevant information to venue pages?
I am a coder and avid Foursquare user. The basic information about venues is cool (location, photos, tips, etc.), but while I have my meal (in the case of a restaurant) I'd like to have more to read about the venue, such as the back-story, i.e., what's the history of the place, when was it founded, by who, and other interesting facts about the venue.
I thought connected apps would be the answer and that perhaps I could write a simple wiki to integrate with the venue page for users to provide their knowledge about the venue. But it seems from what I've read that's not the the intent of a connected app or the API. Am I correct is this assumption? And if so, can this idea be dropped into the Foursquare suggestion box? I think it would make a great value added feature - especially for us nerds who like to read.
This is a great use case for connected apps. Connected apps can reply to check-ins with up to 200 characters of text, and a link to more content. This can be used to provide additional information about the venue. Take a look at https://foursquare.com/apps/ to see examples of connected apps, and the kinds of responses they give to check-ins.
The talk of internet town today is the SNAFU that led to dozens of Facebook users being led by Google search to an article on ReadWriteWeb about the Facebook-AOL deal. What ensued in the comments tread is quickly becoming the stuff of internet legend.
However, behind the hilarity is a scary fact that this might be how users browse to all sites, including their banking and other more important sites. A quick search for "my bank website login" and quickly click the first result. Once they are there, the user is willing to submit their credentials even though the site looks nothing like the site they tried to reach. (This is evidenced by the fact that user's comments are connected to their facebook accounts via facebook-connect)
Preventing this scenario is pretty much out of our control and educating our users on the basics of internet browsing may be just as impossible. So how then can we ensure that users know they are on the correct web site before trying to log in? Is something like Bank of America's SiteKey sufficient, or is that another cop-out that shifts responsibility back on the user?
The Internet and web browsers used to have a couple of cool features that might actually have some applicability there.
One was something called "domain names." Instead entering the website name over on the right site of your toolbar, there was another, larger text field on the left where you could enter it. Rather than searching a proprietary Google database running on vast farms of Magic 8-Balls, this arcane "address" field consulted an authoritative registry of "domain names", and would lead you to the right site every time. Sadly, it sometimes required you to enter up to 8 extra characters! This burden was too much for most users to shoulder, and this cumbersome feature has been abandoned.
Another thing you used to see in browsers was something called a "bookmark." Etymologists are still trying to determine where the term "bookmark" originated. They suspect it has something to do with paper with funny squiggles on it. Anyway, these bookmarks allowed users to create a button that would take them directly to the web site of interest. Of course, creating a bookmark was a tedious, intimidating process, sometimes requiring as many as two menu clicks—or worse yet, use of the Ctrl-key!
Ah, the wonders of the ancients.
The site could "personalize" itself by showing some personal information,
easy recognizable by the user, on every page.
There are plenty of ways to implement it. The obvious one:
under first visit, the site requires user to upload some avatar,
and adds user's id to the cookies. After that, every time the user browses
the site, the avatar is shown.
When I set up my online bank account, it asked me to choose from a selection of images. The image I chose is now shown to me every time I login. This assures me that I am on the right website.
EDIT: i just read the link about the BoA SiteKey, this is apparently the same thing (it sounded from the name like a challenge-response dongle)
I suppose the best answer would be a hardware device which required a code from the bank and the user and authenticated both. But any of these things assume that people are actually thinking about the problem, which of course they don't. This was going on before internet banking was common - I had a friend who had her wallet stolen back in the 90s, and theif phoned her pretending to be her bank and persuaded her to reveal her PIN...
When the user first visits the site and logs in, he can share some personal information (even something very trivial) that imposter sites couldn't possible know - high school mascot, first street lived on, etc.
If there's ever any question of site authenticity, the site could share this information back to the user.
Like on TV shows/movies with the evil twin. The good twin always wins trust by sharing a secret that only the person who's trying to figure out who the good twin is would know.
You cannot prevent phishing per-se but you can take several steps each of which do a little bit to mitigate the problem.
1) If you have something like site-key or a sign-in seal, please ensure that these cannot be iframed on a malicious website. Just javascript framebusting may not be enough as IE has security="restricted".
2) Be very consistent about how you ask for user credentials - serve the login form over SSL (not just post-back over SSL). Do not ask for login on several places or sites. Encourage third parties who want to work with user data stored on your site to use OAuth (instead of taking your user's password).
3) You should never ask for information via email (with or without link).
4) Have a security page where you talk about these issues.
5) Send notification on changes to registered phone, email, etc.
Apart from above, monitor user account activity - such as changes to contact information, security Q&A, access, etc (noting time, ip, and there are several subtle techniques).