1. Best Practices
  2. Sign Up Best Practices

Why this is important

Onboarding a customer into a CRM powered experience offers a trade off – share your identity and a means to contact you in exchange for rewards. Over many years Thanx has tested dozens of variations of onboarding experiences. The flows below are the current state of our own flows.

As noted in our guide on Credit Card enrollment, these flows have also been approved by our card-linked partners at Visa, Mastercard, and American Express. Using these flows as they are will ensure a speedy certification of your application. Changing branding, fonts, colors, etc, are unlikely to materially affect that timeline, but wording and content should remain as they are.

How Thanx does this

The signup flows below use story telling, progressive data capture, and incentives to encourage customers to enroll in a loyalty program. There are small variations to this flow based on the following parameters:

  • Whether cards captured are intended to be used for payment later
  • Whether a credit card is required to redeem a signup reward
  • The type of signup reward

Authentication

Thanx SSO authenticates the user via a password-less flow using email authentication, rather than a password. This reduces the friction of a user having to manage yet another password as well as reduces the friction of transitioning an existing user-base to Thanx. It also makes creating an account as simple as entering an email address – as soon as one is entered, that customer can be addressed by the marketing tools. By breaking the flow out the user’s account is progressively enhanced as the user completes each screen, but the very first one – the email address – results in an addressable account.

Signup and log in

Signup and log in each have their own screen, as users found a single input confusing for both use cases. Make sure that a return user is recognized in the signup view, while a new user in the the log in flow should see an error that their account is not found.

E.g. If a known customer enters her email address on the signup screen, they should be prompted to click the magic link emailed to them to access their existing account. However, if a user clicks “log in” and types in an unknown email address, we display an error that the account cannot be found. This is because consumers sometimes create an account (me@gmail.com) and then, returning to their account on another device, they choose “log in” because they know they have an account, but they enter a different email (me@work.com). This should not create another account, but rather inform them that that address is unknown.

Signup flow

Non-ordering

Card not stored for payment purposes

The conversion rate of this flow (% of users who create an account who then link a card) hovers between 50% and 60% depending on the brand and the signup incentives offered.

Thanx tells a story leading up to the card ask screen to explain to customers the value of linking their card. We try to ask for only critical information up front, so it doesn’t feel too tedious, and the account progressively becomes more complete, but is immediately addressable.

Ordering enabled

Card stored for payment

The main difference in this flow and prior example is on the last screen where we ask for more card details upfront (expiration, etc), because it will save time for the customer at checkout when they order online later and avoid the perception of having to enter the card twice.

Notice the back arrow should a customer decide they want to back out and do this step later, by selecting the manual receipt upload option.

Card required

Available for ordering and non ordering experiences

This variation can be enabled for order and non-ordering experiences; the primary difference being that the signup incentive (intro reward) is locked. To unlock the reward a customer has to enroll their card for rewards. We don’t recommend using this with % progress rewards, as it quickly adds complexity on top of the locked experience.

Design guidance

This flow prioritizes data capture thusly:

  • email – customer is immediately addressable with email campaigns.
  • card number – purchases are tracked as soon as a consumer completes this step.
  • name, favorite location, phone number, etc – if a customer abandons the flow before reaching or completing this step, their account is still active and tracking their purchases.

In mobile applications, the prompts for push notification access, GPS access, etc, are all after these prompts.

Its okay to let users skip these steps and do them later, so long as there is an incentive in place to do so: i.e. unlock a reward, place an order, etc.

Log in

Magic link experience

Customers need to enter only their email address to access their accounts. They should be shown a screen instructing them to go find the link sent to their email account. Clicking that link should return them to their prior state (in mobile app, or in a browser, etc). This screen should have a back button, a means to re-send the link, and a way to contact support.

Be sure to emphasize to the customer that they should open their email on the device they are currently on.

How other merchants do this

Dig app

Rewards tab with tiers, and cart with earned reward

How to do this with our APIs

In order to interact with the Thanx API you will need a user’s authentication token. This requires either that they authenticate using Thanx’s magic link technology, or that you authenticate them using your own authentication implementation. If you choose the latter, your system will be responsible for account creation and authentication. This limits which marketing tools the brand can use within the Thanx platform (for example, our referral program won’t be available, because that program invites users to create accounts using our flows).

We recommend that your experiences do not expire authentication tokens. This means consumers only need to register once per device.

New customers do not need to authenticate at all; only those with existing accounts on file in the Thanx system. For existing customers, their linked credit cards and personal information will immediately be available to power their access to your program. For new customers, they don’t need to go click a link unless they return on another device, so long as you don’t expire their authentication token.

Requirements for implementation

These are requirements that we have negotiated with our card network partners. All card enrollment experiences must be approved by these partners to use the card linked APIs they provide. While you are free to design these experiences as you like, it may produce significant delays of certification. We recommend using the designs as we have presented them to ensure a speedy deployment of your application.

  • Legal text must be on any screen where you allow a customer to enter their card number and store for loyalty tracking. The legal copy may not be altered.
  • Button must say “Register card”
  • Legal text must be visible at all times on all devices supported
  • ToS and Privacy Policy must be obviously clickable (e.g. darker and underlined)
  • Must comply with standard accessibility guidelines in regards to color contrast and legibility (see: https://accessible-colors.com/)

Design tips from our team

  • Fonts & colors: check font size and color contrast against accessibility standards. To check the optimal contrast for type foreground/background color you can use this tool https://accessible-colors.com/
  • Buttons: should be a min height of 40px (Apple recommends 44px) for a reasonable tap area. On screens with two buttons (ordering enrollment) both must be the same size, though they can differ in visual weight (e.g. color, outline, etc).
  • Forms and inputs: automatically pre-fill values in fields where possible, and let users know which fields are required (or just which are optional), and for longer forms break them down into simple steps (e.g. signup flows are better as a series of input screens).
  • Error handling: be as explicit as possible so users understand why they ran into an error, and give them a means to correct or move forward from there. Include support links in critical flows, where users may need further assistance. See our API docs for how to handle error responses