Contact Importing

Best Practice: Google Developer Accounts for Agencies

Outlines the best practice for managing several customer's Google Developer accounts.

Share:

I’ve heard this question a few times since announcing making it mandatory to add a Google developer account to your CloudSponge settings:

I manage the CloudSponge integration for several customers with one CloudSponge account. Do I need to add a unique Google developer account and Redirect URI for each of my clients?

I have asked the Identity team at Google about this situation. The short answer is:

Yes, this is the best practice.

The best practice is to silo each site by using a separate client-id.
Ideally, the owner of each website should have their own Google developer account and agree to Google’s terms.

The major benefits to using a separate client-id for each website are:

  • preemptively isolates bad actors
  • aligns with the user’s expectations

Isolation

When multiple sites share the same client-id, there is no way for Google to tell the difference between consumers of their services. This is not an issue if all consumers are good actors. It’s a bit like cooperative multitasking in that everything works well if each user of the shared resource behaves responsibly. However, a malicious or error-prone actor can abuse the system and damage the reputation for all actors.

Is this an issue for your application? It depends. If your application is fully managed by your team and your customers are unable to directly access the data from Google’s API, then the risk might be low for you. On the other hand, if your CloudSponge integration allows your customers to access contact data, you are exposed to the risk that they may abuse their users’ trust and bring down the wrath of Google.

Ultimately, you are responsible for how the data is used when accessed using your developer account. It’s up to you to decide what to do, based on your relationships with your customers.

Expectation Management

The OAuth flow requires end-users to intentionally engage with the decision to share their data with your application. It’s not a foolproof experience and it doesn’t always succeed. In our experience, about half of users who start the OAuth flow will not complete it. Using your own Google developer credential is an opportunity to keep your site’s brand in front of the user despite their focus having left your site.

This result is measurable. We’ve seen the abandonment rate decrease between 2-5% for Google imports. It may be that some users are put-off by seeing the CloudSponge brand in the OAuth consent screen and they don’t complete the flow. When presented with the familiar and expected logo of the website that they are visiting, these users aren’t scared away and complete the consent flow successfully.

When applying this lesson to your customers’ sites, you might to think about how visible your brand is to the users who are meant to import their contacts. Will these users recognize your product name because it’s part of your headline (e.g. “Mandrill by Mailchimp”) or is the association subtle or hidden entirely?

Another consideration is the link to launch the import flow. Say the user is on water.com but clicks a link or image that communicates “Contact Importing (powered by dihydrogenoxide.com)”, they may not be surprised when the OAuth consent form shows the dihydrogenoxide.com brand.

While allowing your customers to share a Google developer account is not mandatory, it does expose the developer account to risks that affect all of your customers. One bad apple can spoil the bunch. Consider yourself warned.

Graeme Rouse, CTO at CloudSponge

Follow @thunderouse

Comments

Try CloudSponge for free in your
testing environment

Get Started

Have a questions or prefer a guided tour?
Schedule a consultation with our Founder.