# Hard vs Soft Signup Wall: Mobile App A/B Test Example

Page: https://alidemirbas.com.tr/en/lab/ab-test-library/tests/hard-vs-soft-signup-wall-mobile-app-ab-test-example

## Hypothesis

A hard wall sends everyone to registration at launch, which may bring more early sign-ups but may also lose people who wanted to see the product first. A soft wall lets guests try the product before the registration trigger, so some may register more willingly; which wall yields the higher registration rate, measured over an identical follow-up period, depends on that trade-off.

## When to run this test

Funnel drop-off at the registration screen, survey answers from people who wanted to look around without an account, or a pile of registration support requests suggest the wall's design is shaping sign-up; the test also helps if you have not yet decided how strict the wall should be. If the soft wall does better, guests register at the trigger after trying the product; if the hard wall does better, early sign-ups also complete the first meaningful action. Settle the guest scope, the registration trigger and how guest data moves into the account first, or the test measures a half-built flow rather than two walls.

## Primary metric

**Registration rate**: Measure registration per eligible assigned user over the same period for each registration wall.

## Other metrics

- **First post-registration action rate**: Compare completion of a predefined first meaningful action over the same follow-up period.
- **Guest-to-member conversion**: Report this within the guest experience as a diagnostic; there is no directly comparable control event.
- **Support contact rate**: Track sign-in or account-related support requests.
- **Seven-day active rate**: Compare all eligible assigned users over the same seven-day window, not only those who register.

## What to check before and during the test

- **Registration wall**: Compare mandatory registration at entry with registration after a predefined guest experience.
- **Guest scope**: Set guest features and the later registration trigger before launch.
- **Sign-in methods**: Keep the same account and social sign-in options.
- **Guest entry**: Make the guest path clearly visible in the soft-wall arm.
- **Eligibility**: Include users without an account and review eligible returning users separately.

## What to watch when reading the result

- Compare the registration rate across all eligible assigned users in both arms, using one fixed follow-up period. More registrations do not count as a win if the first post-registration action rate or the seven-day active rate falls. Guest-to-member conversion exists only in the soft-wall arm, so report it as a diagnostic, not as a comparison between arms.
- Do not generalize beyond this guest scope and this registration trigger; if you change the guest scope along with the wall, you cannot tell where the difference came from. Review eligible returning users separately, and track sign-in and account support requests in both arms.
- If work done in guest mode is not merged into the account at registration, or critical data is lost, the soft-wall result does not reflect the real experience. If support requests mention lost data, fix the flow before you read the result.
- If the two registration rates end up close, the walls may be reaching similar levels by different routes, early with the hard wall and later with the soft one. Do not shorten the follow-up period; check the gap between the two registration rates with the [A/B test significance calculator](https://alidemirbas.com.tr/en/calculators/ab-test) and make the call together with first actions and active use.

## Frequently Asked Questions

### How do hard and soft registration walls differ?

A hard wall requires signup before use. A soft wall permits a defined guest experience. Fix the guest scope and signup trigger beforehand, and keep authentication options consistent.

### Can guest-to-member conversion be compared across arms?

Not directly when only one arm provides guest access. Use signup per assigned eligible user as the primary outcome and guest-to-member conversion diagnostically.

### Which outcomes matter besides signup?

Inspect activation and active use over equal follow-up windows across all assigned users. Monitor account-related support rather than evaluating only people who registered.

### What should happen to guest data after registration?

Preserve important work and merge it appropriately into the account. Do not lose it at signup. Make the guest-continuation route discoverable.
