FREQUENTLY ASKED QUESTIONS

01 Overview & WAM model

 

What is WAM?

WAM is a white-label infrastructure layer that enables a platform to verify and reward real-world activity initiated through its existing user experience.

When an agreed outcome such as a visit, transaction, event attendance or repeat visit is verified, the participating local merchant funds the agreed economics. The platform can reward the user and retain an agreed share as incremental revenue.

 

Is WAM a separate consumer app?

No. WAM is not intended to operate as a separate consumer destination. The experience is integrated into the platform’s existing interface and presented under the platform’s brand.

WAM provides the underlying activation, verification, reward and merchant-settlement capabilities.

 

What problem is WAM designed to solve?

Social and community platforms often create real-world intent but primarily monetize the activity before the event through advertising, subscriptions or other digital products.

WAM adds a merchant-funded outcome layer so the platform can capture value when platform-generated intent produces a verified real-world visit or transaction.

 

How does WAM work?

The full WAM Loop has seven commercial and technical stages. The user does not manually complete seven separate tasks; several stages occur behind the scenes.

 

Seven-stage WAM journey

1. Platform issues branded points. The platform creates the platform-branded reward currency and keeps the experience under its own brand.

2. Merchants buy points. Participating local merchants fund platform-branded points and the agreed campaign economics.

3. Merchant offers shown on your platform. Relevant offers appear inside the existing platform journey.

4. More user engagement on your platform. The user activates the offer, invites others or indicates an intention to participate.

5. Outcome is verified. Users meet and spend at a local merchant; the agreed visit, transaction or other outcome is confirmed.

6. Points to users / revenue to platform. The user receives the agreed reward and the merchant-funded economics generate platform revenue.

7. Users share the experience on your platform. Sharing, rewards and new offers can trigger another real-world activity and restart the loop.

 

Who pays for the reward?

The participating local merchant funds the economics of the verified outcome. The payment can be allocated among the user reward, the platform’s revenue share, WAM and agreed delivery or technology costs.

The allocation must be transparent and commercially viable for all parties before launch.

 

Who owns the customer relationship?

The platform retains its relationship with the platform user. The merchant retains its relationship with its own customers and loyalty members.

WAM does not create an independent consumer relationship that competes with either party. Data-use and commercial rights should be defined explicitly in the deployment agreements.

 

What does WAM not replace?

WAM is not intended to replace the platform’s recommendation algorithms, advertising stack, brand, user experience, data governance or merchant relationships.

It is also designed to work alongside local merchant loyalty programs rather than displace them.

 

Why use platform-branded points rather than merchant-branded points?

Platform-branded points make the platform the visible owner of the user experience and allow a common reward logic across multiple participating merchants.

A deployment can still interoperate with merchant rewards or loyalty currencies where the platform and merchant agree. The exact reward architecture is a commercial and technical design choice, not a fixed requirement.

​

​

02 Product & user experience

 

Does the seven-stage WAM Loop mean users must complete seven steps?

No. The loop describes the commercial and technical system. A user-facing journey can be as simple as seeing a relevant offer, choosing to participate, completing the real-world activity and receiving the platform’s points.

Merchant funding, verification, settlement and platform revenue allocation can happen behind the scenes. Sharing can remain optional.

 

Could rewards make the platform feel like a discount or coupon service?

That is a product-design risk to manage, not a required feature of WAM. The platform controls how the offer is presented, which users see it, which activities qualify and how points are earned and redeemed.

A pilot should monitor user sentiment, opt-outs, engagement, retention and complaints alongside redemption. More reward use is not a success if it weakens trust in the core product.

 

How is WAM intended to increase user engagement?

WAM creates an additional reason to return to the platform before, during and after real-world activity: discover an offer, coordinate with others, receive a reward and optionally share the experience.

The hypothesis is stronger and deeper participation across the platform. The actual engagement effect must be measured in the pilot rather than assumed.

 

Is sharing the experience mandatory?

No. Sharing should be optional unless a specific campaign clearly and lawfully defines otherwise. The user should not have to publish content in order to receive a reward for an otherwise eligible verified outcome.

 

How are offers selected for users?

The platform should remain in control of relevance and presentation. WAM can support offer eligibility and reward logic, but the host platform should decide how offers fit its recommendation, ranking and product policies.

The pilot should begin with a limited number of journeys and merchant categories so the platform can assess relevance and user response.

 

Can the platform decide which merchant categories and markets are eligible?

Yes. The platform should be able to define markets, merchant categories, user segments, offer types and campaign rules within the agreed deployment model.

This allows categories with poor brand fit, regulatory complexity or weak economics to be excluded.

 

What happens if a merchant provides a poor experience or disputes a reward?

The platform’s reputation must be protected. A deployment should include merchant eligibility standards, clear offer terms, support and dispute procedures, and the ability to suspend a merchant quickly.

The pilot should track failed reward fulfilment, disputed outcomes, merchant and user complaints, support cases and time to resolution.

​

​

03 Technology & verification

 

How lightweight is the integration?

“Lightweight” means the pilot is designed to avoid a platform-wide rebuild; it does not mean zero engineering work.

The first implementation should be limited to selected user journeys, a defined merchant group and agreed verification and reward methods. Technical discovery should establish the actual integration scope, security requirements, latency, maintenance effort and responsibilities before launch.

 

Which platform systems would typically be involved?

The exact interfaces depend on the deployment. A pilot may touch selected offer surfaces, user or campaign identifiers, reward status, verification events, reporting and settlement data.

It should not require WAM to replace the platform’s core identity, feed, recommendation, ad-serving or profile systems.

 

Does WAM require new hardware at local merchants?

Not necessarily. A merchant may participate using an existing payment, booking, POS, loyalty, QR, check-in or other approved verification method.

New hardware should only be introduced when it materially improves verification or operations and is justified by the merchant economics.

 

How are offline visits and transactions verified?

WAM does not require one universal verification method. The method should match the outcome, merchant systems and privacy requirements.

• Consented transaction or POS confirmation.

• Platform or merchant check-in.

• QR or another user-initiated confirmation.

• Time-limited location validation or geofencing where appropriate.

• Merchant booking, loyalty or other system data.

• Another mutually agreed verification method.

​​

Where transaction data is available, it may provide stronger evidence than location alone.

 

Will WAM track users’ location continuously?

Continuous background location tracking should not be the default verification model. Where location is used, WAM should use the least intrusive method capable of confirming the agreed outcome.

If transaction data, a check-in or another event can verify the outcome, continuous location monitoring is unnecessary.

 

What happens when verification fails?

The campaign should define what counts as verified, rejected, duplicate, pending or disputed before launch.

A failed or ambiguous event can be held for review rather than rewarded automatically. The pilot should measure false positives, false negatives, disputes and resolution time.

 

How does WAM prevent fraudulent visits or duplicate rewards?

Verification can combine transaction confirmation, merchant-system records, campaign tokens, booking information, check-ins and limited device or location signals.

Controls should identify duplicate submissions, reused transactions, expired offers and impossible activity patterns while remaining proportionate and avoiding unnecessary surveillance.

 

Can existing merchant loyalty or POS APIs be used?

Potentially, yes. If the merchant’s systems expose suitable interfaces, they can support outcome confirmation, member matching, reward transfer or reconciliation.

This is deployment-specific and should not be presented as a prerequisite for every merchant.

 

Can WAM integrate with our existing advertising and merchant systems?

WAM is designed to build on the platform’s existing advertising infrastructure and current merchant relationships rather than create a parallel commercial organization by default.

The exact integration with CRM, ad-management, billing or merchant systems must be defined during technical and commercial discovery.

 

​

04 Data, privacy & security

 

What information does WAM need?

WAM should process only the information necessary to activate an offer, verify the agreed outcome, calculate the reward, prevent misuse and produce appropriate reporting.

• A pseudonymous user or campaign identifier.

• The activated offer and eligibility conditions.

• The participating merchant.

• Time or approximate period of the verified outcome.

• Confirmation that an eligible visit or transaction occurred.

• Transaction value when needed for the agreed reward.

• Reward and settlement status.

• Limited fraud-prevention and audit information.

​​

Detailed product-level purchase information should not be required unless it is genuinely necessary for the agreed campaign.

 

How will WAM address GDPR requirements?

GDPR compliance cannot be established through a general website statement. It depends on the specific deployment, purposes, legal basis, data flows, contracts and safeguards.

Before launch, the platform, WAM, technology partners and participating merchants should document controller/processor roles, lawful bases, user notices, retention, security, data-subject procedures, transfers, subprocessors and whether a Data Protection Impact Assessment is required.

 

Who is the data controller?

The answer depends on the implementation. The platform will normally be the controller for activities performed for its own users and commercial purposes. A merchant may be an independent controller for its customer and loyalty records.

WAM and enabling technology providers may act as processors where they handle personal data solely under documented instructions. Joint-controller relationships must be assessed rather than assumed.

 

Will users be required to give consent?

Not every processing activity under GDPR requires consent. Another lawful basis may be more appropriate for contractual fulfilment, security, fraud prevention or necessary platform operations.

Freely given and informed opt-in consent may be required for certain features, particularly precise location, optional cross-platform matching, non-essential tracking or certain personalized marketing activities.

 

Will merchants receive personal information about platform users?

Not automatically. The preferred model is to provide only the information required to fulfil the offer, verify the outcome or administer an agreed reward.

In many cases a campaign token or pseudonymous identifier can be used instead of disclosing the user’s platform identity.

 

How long will personal data be retained?

Retention should be defined by data category and purpose rather than applying one indefinite period to everything.

Settlement records, fraud-prevention records and user-level operational data may require different periods. Aggregated reporting should be anonymized where individual-level data is no longer necessary.

 

Can users access or delete their information?

The operating model should support applicable data-subject rights, including access, correction, deletion, restriction, objection and portability where relevant.

The platform-facing privacy notice should explain how requests are made and which organization is responsible for responding.

 

Does WAM sell personal data?

WAM’s proposed role is verified outcomes, rewards and settlement, not an independent consumer-data marketplace.

The final agreements should prohibit reuse of personal data for unrelated purposes unless a separate lawful basis and transparent user notice exist.

 

How will international data transfers be handled?

Where personal data is transferred outside the EEA, the parties must establish an appropriate transfer mechanism and assess the legal and technical risks.

Regional processing and storage should be preferred where they materially reduce legal and operational risk.

 

Will a privacy and security assessment be completed before launch?

Yes. Privacy and security should be part of pilot design. Before live user data is processed, the parties should review data flows, GDPR roles and lawful bases, notices, subprocessors, security controls and the need for a formal DPIA.

The pilot should validate consent flows, data minimization, verification accuracy, deletion procedures and operational responsibility alongside commercial KPIs.

​

 

05 Merchants & loyalty

 

Does WAM replace a local merchant’s loyalty system?

No. WAM is designed to complement existing merchant loyalty systems.

A merchant loyalty program normally manages the merchant’s direct customer relationship, points, tiers and retention. WAM helps the platform generate, attribute and verify a platform-originated real-world outcome.

 

How can WAM work alongside an existing merchant loyalty program?

WAM can operate as the platform-led acquisition and activation layer while the merchant’s loyalty system continues to manage the merchant-owned retention relationship.

• Outcome confirmation: the loyalty system can confirm an eligible visit or transaction.

• Member matching: a pseudonymous identifier can connect an activated platform offer with a merchant loyalty transaction.

• Reward transfer: WAM can trigger an agreed benefit inside the merchant’s existing program where technically supported.

• Acquisition-to-retention handover: WAM can generate a first verified visit and the merchant loyalty system can manage continued loyalty.

• Campaign coordination: eligibility and reward rules can prevent incompatible offers or unintended duplication.

 

The integration should exchange only the information required to verify and administer the agreed outcome.

 

Can users receive both a WAM reward and a merchant loyalty reward?

Yes, if the merchant and platform choose to permit reward stacking. Campaign rules can allow both benefits, restrict the user to one benefit or adjust the WAM reward when merchant loyalty points are also issued.

Controls should prevent the same transaction from being counted or rewarded more than once.

 

Can merchants participate without an existing loyalty program?

Yes. An existing loyalty system is not necessarily required. A merchant may participate through payment, booking, POS, QR, check-in or another approved verification method.

 

Who recruits and onboards the local merchants?

WAM should not be presented as having a ready-made merchant network in every target market.

The preferred route is the platform’s existing local-advertising organization, merchant relationships and advertising partners, with WAM and implementation partners supporting the rollout as agreed. A pilot can begin with approximately 20–50 merchants.

 

Why would a merchant pay for WAM?

The merchant proposition is measurable customer acquisition rather than visibility alone. The merchant pays for an agreed verified outcome and can compare campaign cost with visits, transactions, repeat activity and attributable or incremental revenue where the data allows it.

Merchant willingness to pay is a hypothesis to validate by category and market.

 

Which merchant categories are best suited to an initial pilot?

The first categories should combine frequent real-world visits, sufficient transaction value, clear verification and a reasonable ability to recruit merchants.

The final category choice should reflect the host platform’s user behavior and local-market density rather than rely on a universal WAM category list.

 

Who owns the merchant relationship?

The platform should be able to retain its commercial relationship with participating merchants where that matches its operating model.

WAM provides infrastructure and agreed delivery support; it should not automatically disintermediate the platform’s existing merchant or advertiser relationships.

 

Who carries the financial liability for points and unredeemed rewards?

This is a deployment-specific accounting and contractual question that must be defined before launch.

The commercial agreement should specify who issues the reward currency, when merchant funds are recognized or reserved, how unredeemed balances are treated, and how expiry, refunds and disputes affect settlement. WAM should not imply a universal accounting treatment.

 

Do merchants need to pre-fund points or pay after verification?

Either model may be possible depending on credit risk, settlement design and platform policy. The pilot should choose one clear settlement method and document merchant funding, reconciliation, refunds and non-payment handling before live use.

 

​

06 Advertising & monetization

 

How does the platform make money?

Local merchants fund the agreed outcome economics. Gross merchant-funded revenue is created when the defined verified outcome occurs.

The platform’s retained amount depends on the merchant fee, user reward, WAM economics and agreed operating costs. That net retained amount is what drives platform revenue and ARPU.

 

Will WAM cannibalize our existing advertising revenue?

WAM is designed as a complementary performance product: the existing ad stack monetizes reach, impressions, clicks, leads and media inventory, while WAM adds payment for agreed verified offline outcomes.

 

How should a pilot measure whether WAM revenue is genuinely incremental?

If WAM revenue is offset by an equivalent decline in existing ad revenue, the intended incremental economics have not been demonstrated.

The platform should track the source of each participating merchant’s campaign budget and report any displaced platform advertising separately.

Relevant budget sources can include new performance-marketing spend, loyalty or promotion budgets, offline marketing budgets and budgets moved from existing platform advertising.

 

Is WAM an advertising product or a loyalty product?

It contains elements of both, but the platform-facing proposition is a merchant-funded performance layer around verified real-world outcomes.

The platform can sell it alongside existing advertising while using loyalty mechanics to reward users and reinforce repeat activity.

 

Can WAM be sold through our existing advertising organization?

That is the preferred scaling model where the platform already has local merchant or advertiser relationships. WAM is designed to build on the platform’s existing advertising infrastructure and current partners rather than require a completely separate sales channel.

 

What is the difference between the merchant fee and net platform revenue?

The merchant fee is the gross amount funded for the agreed outcome. Net platform revenue is the amount retained by the platform after the agreed user reward, WAM economics and delivery costs are accounted for.

The two figures should never be presented as if they were identical.

 

Does WAM monetize every real-world activity generated by the platform?

No. Only eligible activities covered by an agreed campaign, merchant and verification method should generate WAM economics.

This is important for user trust, attribution quality and merchant willingness to pay.​