Action with different fulfilment URL based on user's location - actions-on-google

I work for a company that is building a Google Action which will be available in AU, NZ & UK. Depending on the location of the user, the fulfilment URL needs to be different as each country has its own APIs, etc.
We could achieve this easily by deploying three separate apps, restricted to their particular country, each having their own fulfilment URL. However, if my understanding is correct, they would all have different invocation names which is not ideal.
Another way we could potentially achieve this is by making the user choose which market they want (AU, NZ, UK) on the account linking page and then use the APIs for that market. However it doesn't seem to be a great UX.
Ultimately the key goals we're trying to achieve are
Users in AU, NZ & UK can all invoke the Google Action by saying "Ok Google, Open App", rather than "Ok Google, Open App NZ", "Ok Google, Open App UK", etc.
Users don't have to choose market (AU, NZ, UK) they belong to - it happens automatically
We can use the correct API based on the market the user belongs to.

There is no way to have different fulfillment URLs for the same Action.
You also have a slight issue when getting their location - you need to request it explicitly from them. Once you have this, however, you can store it (with their permission) to use it again in future requests, so you only have to do it once.
You will need to check to make sure it is one of the locations you serve, and you may want to allow them to change it (what if someone from the UK is traveling to AU?).

Related

How to store data for a household

I'm looking for a way to store data for a Google Assistant action for all devices/users in a household, without requiring voice matching to identify a user.
I know you can store data in user.storage, but I don't necessarily want to require voice matching to link to a user, and if I use user.storage the data will only be associated with one user. I just want anyone on any of the devices (Google Home) in the household to be able to use the data persisted in the action.
One approach could be to obtain the device ID (if possible) when setting up the action and store the data by device ID. Then link all other devices in the household by device ID through the list of devices associated with the original user's account (if that's possible). Any other options?
This is currently not possible, there's no way to save data and have everyone in the household access it. I'm sure you've already seen the documentation on Save Data in a Conversation.
On shared devices like Smart Displays and Speakers, personal results are turned off by default. They can be enabled again following these instructions:
Open Assistant settings on your Android phone
Select device in "Assistant devices"
Turn Personal results on.
But this means other household members can see personal results, e.g. Calendar entries.
To determine if you will be able to use userStorage, you can use the recently launched GUEST/VERIFIED flag, see documentation here.
User storage is designed to work at a user-only level. If you don't have something like voice match setup, user storage will not persist. The best approach to having family or multi-person data sharing would be to use something like Google Sign-In to get their email, and then have a companion service like a website where users can share access with other emails. Then your service can pull from a common data source.

How facebook detects my location so precisely only based on IP address?

I have two-step authentication on facebook. I just tried to log in from my home PC but didn't write second step code.
I've got notification that somebody (me) was trying to login to my account and location was so precise (within 2 meters).
I wondered how facebook detects location so precisely only based on IP?
Today geolocation is in the core business of Marketing companies, there's a very developped market of customer data, so tons of mobile apps and services collect data such as usual IP addresses, personal information, interests, locations.
That information gets reselled to data brokers, aggregated, corrected. And then Facebook or others can buy that data, merge it, implement corrections and so and get tables for matching IPs and locations that are not public, it seems.
However they offer a high level API to perform market targeting which seems to use that data:
https://developers.facebook.com/docs/marketing-api/buying-api/targeting#location
In your case it was precise because they may have a good dataset based on your privacy settings experience, not only with facebook but with other geo-located apps. In my case their guess is wrong by hundreds of Km, because I was behind a corporate proxy.

Automate distribution of redemption codes for Custom B2B app

I have built a Custom B2B app for one of our clients. My question is how to automate the distribution of the redemption codes.
I have already looked at some of the MDM providers. Their solutions are too expensive and all we really need is a way to distribute the app from a webserver, not manage a bunch of mobile devices.
As you probably already know, when a client buys a Custom B2B app through the Apple VPP program, they get a spreadsheet with valid redemption codes for the number of licenses they have built. This spreadsheet has 2 columns: 1) redemption code 2) URL to redeem the code
I want to provide my client with a URL where they can send their users to download the app. They just don't have the expertise/infrastructure to distribute the app themselves. And emailing clients is not going to work.
I'm not a web guy, but it seems to me that we could write a webpage that would look at the spreadsheet for the next available activation code and then redirect the user to the associated URL. I'm not concerned with the number of licenses they distribute since I have another way of auditing the real number of users (Flurry). So I want this to be as painless as possible.
In fact, I have multiple clients and want to provide them each with their own URL for their clients. It seems like this shouldn't be too difficult to code.
The problem is, I'm not the guy to write that code. Any ideas on how best to do this?
Assuming that you don't want to show the user a website you should be able to do this with an online service like parse.com and the features it offers.
From a user POV you would supply them with a link which directed them to parse.com with a path and parameters indicating the action to be taken (get app) and what account is associated. This would redirect the users browser to the appropriate destination.
The main issue (and this applies to any solution) is knowing if the user actually followed through and used the code. i.e. should it be removed from the DB so it isn't offered to another user in future. Then you would update the DB each time you get a new spreadsheet.
Anyway, this could be achieved with a little javascript in parse.com, specifically, by using cloud code which can interrogate and modify the DB and then redirect the user.
Obviously if you need user authentication of some kind or other restrictions then you would need to start adding some web interface on top of this in order to collect the details.

reverse geolocation with open graph action

I am developing an application which has an associated lat,long with the action in open graph. Presently, the api only allows for a place, so I have created my own location object which can be a property of the action.
The problem I perceive here is that this will not form part of the action in a very Facebook way.
I do not want to use Facebook places, nor do I want to have the use create a place when performing an action.
I don't need a lot of granularity, instead, just need "near $locality", such as a village name or national park if no residential addresses exist. This seems to be what happens with the Facebook messages.
Do we know a way of getting low fidelity data from Facebook or other (free) source which allow for locality information to be attached to an action?
Cheers

Social Network (Facebook, Twitter, etc) User Account Integration (duplicate scenario)

So there are definitely many tutorials out there regarding how to integrate various individual social network authentication/registration into existing user accounts. But the scenario I can't seem to find out much information about is if a user signs into your account with different social network credentials. For example:
Scenario #1
User registers on site using site's authentication.
User then signs in/registers on site using Facebook Connect.
User then signs in/registers on site using Twitter.
How do I integrate all of these into one account?
Obviously once a user is registered, they can add other social network associations in the account settings pages. But I am more concerned if they register via the other social network not remembering they are already setup.
My general thoughts are trying to figure out a way to use the "username" or email to try and guess and present the user a way to combine accounts right there.
Anyone have any thoughts?
following up -
if your users can't remember that they've signed up previously, well, best of luck to them in general ;)
much as you described, i'm planning on giving users the option to link additional accounts once they have signed in by one means or another.
but as far as cross-checking, there's only so much you can do. many social network APIs do indeed provide email addresses (once you've busted in through OAuth) but these may be accessible only if a user has elected to make his/her address public, which is not guaranteed.
also not guaranteed is that the user used the SAME email address for each social network account, so even if you manage to retrieve an address it may or not be of any use to you.
finally, if you find matching email addresses via such means, it might be advisable to prompt the user to link accounts rather than assume he/she wants this done automatically. some people like to maintain multiple personalities. i.e. "it looks like you are also signed up with twitter - do you want to link your accounts? it will make your life seem worth living."
you might consider offering incentives to link user accounts or to provide an email address (up to you of course to figure out what these might be, based on the functionality of your website).
solution i am working on, database-side, is to maintain multiple accounts and then if link information is discovered by various means, said link is indicated in a lookup table.
an alternative is once you find a link, attempt to combine all relevant entries for the multiple accounts into one account entity - all i can say about this latter approach is that i would do so with caution as there could be a formidable level of complexity depending on the user's activity level and the complexity of your database schema.
in my (mental/actual) namespace a user who registers the old-fashioned way has a 'standard' account and one who uses a social network has an 'alias' account. then the goal becomes to define where the alias is supposed to point, i.e. create the lookup such that a subsequent login via either means retrieves the relevant information for both accounts (with a preference for displaying personal data for the 'standard' account).
btw i figured out how to make twitter OAuth behave since my last post - you can look at my other answers for details if you're interested.
JB
hi matt,
i'm working on the same problem right
now.
assuming the user starts with regular
site account (which is not
necessarily safe to assume if he sees
all the pretty "connect with XXX
network" buttons!!!), you can use
either OAuth or the javascript APIs
(facebookConnect or #anywhere -
haven't fully figured out the latter
yet and i'm not sure I recommend it as
I don't think it provides as rich an
API as do the backend libraries) to
login to the other sites.
the APIs should return certain
information after a successful
login/redirect from the social network
- such as the user ID and an ACCESS TOKEN which you can then store in your
database in some capacity associating
your 'actual' application user with
the ID of the social network.
when the user returns to the site, you
can then
1 verify cookies set by the social
network services (various schemes
typically verifying a signature, based
on sha1 or md5 hash of your
application data - by which i mean the
data you get when you register your
app with twitter/facebook, typically a
consumer key, application ID, etc. -
with the received cookies) so you know
the user has logged in with the social
network
2 find your database entry association
as described above
3 login your user manually based on
the assumption that facebook/twitter
connection is secure.
caveat: this is only as secure as your
implementation (or as secure as
facebook/twitter's implementations, if
you prefer...)
although twitter's OAuth does not
currently seem to work quite right,
their general description of the
process is pretty informative:
http://dev.twitter.com/pages/auth
good luck.
J
I have been contemplating adding FB auth to our app, but we know that our returning users might click it and complete checkout for a new item, and then be surprised to not see any of their existing orders. To solve this, when a user clicks the 'Login with Facebook' item, we are using that click to fire a dropdown menu with two options:
[ Login with Facebook ]
[ Create new account ]
[ I have an account ]
If the user clicks 'I have an account' we send them to FB auth and return email from FB to our app. We compare that email to our existing users. If we match, we add the FB creds to the user. If no match, we throw an alert:
The email you have with FB does not match any of our accounts. To log in to your existing account, login with your email below, or update the email in your Facebook account
This allows the user to create a whole new account, if they want to keep them separate, without needing a new email service. While this is an edge case, it is a feature.