Blog - Campaign Design

When a completed task becomes a useful contribution

Define what a contribution changes, how it is verified and when it earns a reward. A practical framework for Web3 campaign rules.

By Claimr Team4 min read

A task can be complete while the intended contribution is still missing. A participant submits feedback, but the report cannot be reproduced. A referral creates an account, but the new user never reaches the product. A tutorial is finished, but the first independent action fails.

The campaign needs a definition of what the completion is supposed to change. That definition belongs in the rule, the participant instructions and the report used to judge the result.

Start with the job the campaign serves

Awareness, learning, activation and contribution are different jobs. A social follow can be a reasonable awareness task. It becomes misleading when the team reports it as evidence of product adoption.

Write a sentence that names the audience and the useful outcome. For a developer product, that might be: new developers publish a working test integration. For a community program: members produce answers that resolve recurring onboarding questions. The sentence should be specific enough to tell you what evidence to collect.

Then choose the smallest task that helps someone get there. If the participant needs three preparatory steps, make their purpose clear. A long checklist can hide the fact that only the last action matters to the product.

Translate the outcome into an acceptance rule

A contribution rule needs an event or submission, an acceptance condition and a window. Some can be evaluated automatically. Others need a person to judge the work.

TaskIntended contributionEvidence to checkRule to explain
Complete a tutorialLearn the first workflowA subsequent qualifying product actionWhich action completes the journey
Submit a bug reportHelp the team reproduce a problemSteps, expected result and observed resultDuplicate handling and review timing
Invite a teammateBring a collaborator into the productThe teammate completes the agreed setupWho qualifies and when attribution closes
Publish an integrationDemonstrate a working implementationA successful request or reviewed deploymentSupported environment and acceptance conditions

These are design examples. The exact evidence depends on what the product can observe. A successful request proves that request happened; a separate step may be needed to establish who performed it or whether the integration remains in use.

Make reviewed work predictable

Subjective tasks create a queue. If 300 submissions each take four minutes to assess, the first review pass is 20 hours. That illustrative calculation excludes appeals, duplicate checks and participant support. A modest reward budget can still produce a substantial operating commitment.

Publish a short rubric and show an example of an acceptable submission. Explain whether a rejected entry can be corrected, when a decision will arrive and what happens to duplicates. Assign an owner who can resolve cases where the rubric is ambiguous.

Avoid a scoring system whose only explanation is that the team will decide later. Participants need enough information to choose whether the work is worth doing. Reviewers need a consistent basis for paying it.

Give progress a purpose

Progress should show the relationship between effort and the outcome. A developer might move through setup, a successful test request and a working integration. An achievement can mark the accepted result. A challenge can invite the next useful step.

Competition changes the design. Ranking by raw submission count encourages more submissions, including duplicates. Ranking by accepted work moves effort toward the review criteria, but can still favor people with more time or prior experience. Decide whether the job requires a ranking at all.

Gamification infrastructure makes those choices repeatable through events, rules, progress and outcomes. A team still has to define a contribution that deserves recognition.

Read the outcome and its cost together

Track starts, submissions, accepted contributions, rewards and subsequent use separately. Include review time in the cost of an accepted contribution. Keep the original submission and the reason for the decision so a payment can be explained afterward.

A campaign that accepts fewer submissions can be healthier if the accepted work solves more problems. It can also be too restrictive. Review rejected samples and participant questions before concluding that a lower acceptance rate means better quality.

With Claimr, tasks and progress can connect to the activity your product tracks. Use the campaign to make the desired contribution legible: what to do, what counts, when it clears and what comes next. The useful result is a body of work the team can use and participants can understand.

Keep learning

Further reading

Continue with the sources and practical guides behind this article.

What is gamification infrastructure? (opens in a new tab)Max Rodionov - Claimr guide

The events, rules, state and outcomes behind a repeatable engagement program, with research and a build-or-buy example.

Referral program economics (opens in a new tab)Max Rodionov - Claimr guide

How qualification and reward timing change acquisition cost, with a worked comparison and the limits of the evidence.

The Campaign Guidebook (opens in a new tab)Claimr - Interactive guide

Work through the audience, participant journey, rewards, launch checks and evaluation for your own campaign.

Make the next move

Build a campaign around a useful contribution

Connect the action your team values to a clear task, visible progress and a qualifying reward.

Try live quests