I've guessed the Users Address from their GPS, looking up their location using Google's Places, but the output of that is pretty variable (no locality oftentimes, outside cities a consistent locality field would be helpful to my app). The thing is I do NEED the users home address for my app to work, but they may not be at home when they download the app.
I'd prefer to get their address from contacts. I've looked at a couple of Flutter plugins for accessing the address book, flutter_contacts, etc., but I can't see how you simply get the users details. So how do I request the Users HOME address, HOME email, MOBILE phone, whatever I can get from the device? Age might actually be beneficial too, so I could pivot the app to the needs of those who are using it.
I feel this is such a commonly useful thing it should have its own special permission, rather than the blunt one of exposing their entire contacts address book. So is there a better way of doing it? Less invasive so the user can more easily consent?
There's a special contact called "Profile" that contains the user's details if they bothered to add them on their phones, but in most cases it'll be empty, and anyway, accessing the user's profile requires the "Read Contacts" permission.
It'll be strange to ask the user for the "Read contacts" permission without they understanding why on earth would your app require such a permission "to guess your address" is not a very good reason.
And I suppose might cause some users to uninstall and/or flag your app as potential spyware.
If you app relies on having the user's address, you should instead simply pop a dialog with a question to the user to fill out their address manually.
I've tested the Google Books API now with servers in a few different countries (Germany, UK, Netherlands; it should be in Europe) and realized that the results depend heavily on the request's origin region. For some German books (I search by ISBN) I get 20 or 30 results using the German server but nothing on the others and vice versa.
Is there any way to access the complete database Google has to offer? Note that I'm not trying to access anything like text excerpts or other critical content in terms of licensing. I only need the general information like Title, Authors, ISBN, ...
Thanks for your help!
I have the same problem. I found a paragraph in the documentation under "Using the API" (for Google books) that might explain it:
"Setting User Location:
Google Books respects copyright, contract, and other legal restrictions associated with the end user's location. As a result, some users might not be able to access book content from certain countries. For example, certain books are "previewable" only in the United States; we omit such preview links for users in other countries. Therefore, the API results are restricted based on your server or client application's IP address."
My workaround is to search while using a VPN - that returned the titles in English like I wanted to. If there's another way to solve it I'd gladly hear that too.
Im not an expert in Google Tracking and Adwords and i had a request where a client wants to track the people who submit a contact form on a website, coming from an adwords ad.
So someone lands on a specific site on the clients site via Adwords, then fills out the contact form on that site. Now they want to know how many people coming from adwords ads, are willing to submit the form.
This seems to be very obvious, and i thought there might be already a solution for this.
Conversion Tracking already happens when the form is submitted, but they cannot comprehend whether someone submitted the form coming from adwords or or not.
I´ve been told to save the GET-Parameter from the Adwords-Link inside the database, the website is running on, every time the form is submitted. That doesnt seem to be the right way. Also there are some security issues with that.
Can anyone give some advice, how this could be achieved.
I hope i explained that right.
Thanks in advance.
If you need to save source into DB:
Simpliest way migth be parsing UTM parameters and populate the hidden fields in the form, so you know that user came from AdWords or any other source.
If you are using automatic tagging (which I would recommend), you are going after GLCID parameter, if manual, it's just utm_source.
I would do tracking from all sources (not only AdWords) - it might happen that you also need to know if user came through Facebook, LinkedIn article or so.
More on tracking sources into database here and here. More on AdWords tagging here.
If you only need to know if people from AdWords submit forms (=converts):
Chances are, that you already know. See Google Analytics. Filter out segment of people who did goal of sumbmiting form and see Aquisition -> All traffic.
More on Google Analytics here
You should check and make sure you have auto-tagging enabled. The best way to do this in Google Analytics go into the Admin > Property column > Product Linking section > Adwords Linking.
Once you have Adwords and Analytics linked up simply go back to the Reporting tab and navigate to Acquisition > Adwords > Campaigns as shown here
If you have properly set up your goals in Analytics you can use the Conversion filter to select the goal you want to view and this will show you all goal conversions that came from Adwords.
I'm developing my first iPhone app to make what is effectively an app version of a fantasy league I created for work colleagues.
I am using Parse for the backend of the app. I only want people to be able to register with their work email address ie only if their e-mail address is _#mycompany.com
I'm sure this would be quite easy to someone who knew what htey were doing but I'm kind of new to this so any advice would be much appreciated.
Thanks
You could do this in a number of ways. The easiest way would be to have the validation happen on-device - just check the e-mail address the user has put into the app, and only allow the registration to happen if it matches the domain you want to limit it to.
However, although this is very easy it's also open to abuse and it's not very flexible (if you want to add additional domains, you have to update the app).
Fortunately, Parse offers cloud code, which lets you validate data server-side. Cloud code is written in JavaScript, and you then upload it to Parse. There is full documentation on Parse's website, including examples for validating data.
We want to streamline the user registration and login process. The goal is to reduce the time and effort for users to register and login to our site.
At the same time, we don't want to overwhelm users with choices. We don't like how some web sites present registration/login options via multiple channels (e.g., Facebook, Twitter).
What are the pros/cons of each of these systems? Which do you use, and what are your main gripes?
Offer all of them, don't take the time to ask "why?".
It's always worth it to get users on board.
The biggest (IMO) pro is that you are no longer storing passwords in your db. Leveraging one of those other site's authentication service relieves you of this. It doesn't relieve you of having a secure design. I'm also not sure that your average end user really cares. If your service is highly aligned with one of those services, maybe. However, if you are not targetting those end-users, then probably not.
Rob Conery did a recent write up of his experience with OpenId. This might be a good read:
http://blog.wekeroad.com/thoughts/open-id-is-a-party-that-happened
Hope this helps.
Bob
Well, yes, it does all depend on your user audience.
In any case, I would say that Facebook Connect is probably your best bet due to the sheer number of people using Facebook. Still, as far as I've noticed, it's not really "professional" websites that use Facebook Connect, mostly forums and unofficial (but popular) news blogs.
Many "professional" websites (catering to... well, professionals) will use a normal Register/Login rather than Twitter, Facebook, or OpenID. Still, a professional website would likely need a more professional solution, so I would suggest OpenID, which also supports websites such as Yahoo! Mail and developer communities (such as Stack Overflow!). You can see the full list of sites here.
In all honesty, I don't really think that using a Twitter login would be very efficient. Think of it this way: for one, I've noticed (but I could be wrong) that Twitter is mainly used by the small hobbyist or the people who use it to give updates on things they're doing or making (and sometimes just the people who want to be in on the times). So unless your website is aimed at these type of people, it wouldn't really be useful. On top of that, I don't know of many people who particularly like it, partially because of its over-popularity. Still, it could be the same way with Facebook, but this is all subjective, so if you really want to pick Twitter, go for it.
Anyway, that's my take on things. I don't personally use these systems on websites I've built, but I know how they work.
For one, when you log in using any of these for the first time, they take the user to a new page or open a popup window asking them to confirm if they want to connect their [Whatever] account to your [Website Name]. After that, it's a bit easier to use just because they don't have to keep repeating the process unless they disallow your website on their service.
With OpenID, you have to log in to your OpenID-enabled webpage using http://myusername.myopenid.com/ or myusername.myopenid.com. If they don't choose to remember their password, this can become a bit tedious to type in every time.
With Facebook Connect, it usually automatically connects all of their information to the website, including full name and profile picture (meaning that if they have a profile picture of that snazzy tattoo on their inner thigh, other users will be able to see that).
Finally, as far as I can see, Twitter doesn't do much other than connect whatever name you had on your profile page (if it's "John Doe" or "Weiner Schnitzel", it'll show on your website) and your profile picture, just like Facebook.
To finish up, those are pretty much all the pros and cons that I can tell about the services. Good luck!
What is your target group?
If you want that many normal people uses your application than use Facebook.
If there are many coder / blogger / internet junkies than use Twitter.
If you have a lot of open source guys than OpenID will do the job.
If i'm is not wrong, previously there is a website providing kinda service about providing login platform to allow user connect to your site. Of course it is not free and i was abandon it because of high annual fees and mind change after research being done.
While you using their service to growing your business or website, you can save their time it's true. but honestly, will they really care on how long time taken to connect their facebook with your website either register as a new member in your website. While you can give confidence to you client, they do. they willing to spent few minute to fill up simple information to make an account for them self if they felt they worth to spent the minute to get service from your website.
Totally agreed to what rcravens said, if they connect through third party website, means you are gonna giving you user information to that website. For example, to archive FACEBOOK CONNECT you will need to create an application for them to trust them you only can get authority to access. while they accept and login to your site, it is good for FREE advertise because while they connect, can use their account as medium to post your information to public. BUT mostly site will sell their information gather or share them in any way to some organization who need them for decision.
My point is, how many people using your site and mostly who is using, what characteristic of your site user and so on... everything is no more under your control !!!
Perhaps, you may use it but what if their service shut down few hour for maintainance...
I'd recommend using something like RPXNow (https://rpxnow.com/) or Gigya (http://www.gigya.com/) as an intermediary to the various authentication providers. Facebook and Twitter are notorious for always changing their APIs. It is a pain to keep up with them. These services give you a simple abstraction layer, so that you don't need to change anything on your end when the providers change their APIs.
i like facebook but..
facebook is block in some country.
open id is not famous.
twitter is famous and simple.
so use twitter is the best :)
Use OpenID as it is a standard that is also integrated into many Mail Accounts, like Google or Yahoo. You never know how long Facebook will stay around and therefore it's better to have something people just don't throw away (there Mail address). If you make a nice selection screen (e.g. stackoverflow), the people don't even know that they're using OpenID. If you just want to get authorized Comments, picture uploads for twitter or fb, a game connected with social features don't use it.
Facebook Connect is very usable for one time comments or stuff like this. If you want to store your own data about the user (e.g. blog service, saas), not dependend on "social networks" don't use it.
Twitter Login makes only sense if you connect your service with Twitter, otherwise forget about it.
I would use a hidden OpenID approach.
Facebook is great for keeping tabs on family and friends. Beyond that I, personally, wouldn't use it in support of any other app. It's just not bullet-proof enough from a security/malware standpoint. There is too great a chance someone could have issues of that sort with Facebook and attribute it to your site, whether reasonably so or not.
I like OpenID. Not thrilled with the notion of hitching my wagon to any of the social networking sites/services at all.
Is this a technical or commercial question?
The answer to my mind is it depends what you want to do with the data.
If you just want to provide a service to a broad list of people then the answer has to be to gun for openness, not proprietary - particularly since the open standard is supported elsewhere, Gmail, Yahoo et al.
However, if you want to demographically profile that database at some point to offer targeted services, then you need to understand the questions you're likely to require answered and whether a third party method is going to enable that or not.