Ակցիաներ և լոյալություն

01Ակցիայի կանոնի անատոմիան

Յուրաքանչյուր ակցիա ունի երեք մաս՝ պայմաններ, գործողություն և սահմանափակումներ։ Պայմանները որոշում են՝ արդյոք այն կիրառվում է․ զամբյուղի նվազագույն գումար, կոնկրետ ապրանքներ կամ կատեգորիաներ, հաճախորդի սեգմենտ կամ լոյալության մակարդակ, միայն առաջին պատվեր, ալիք (վեբ կամ հավելված), ամսաթվերի միջակայք, շաբաթվա օր։ Գործողությունն այն է, ինչ ակցիան տալիս է՝ տոկոսային զեղչ, ֆիքսված գումարի զեղչ, ֆիքսված գին, buy X get Y, նվեր ապրանք կամ անվճար առաքում։ Սահմանափակումները վերահսկողության տակ են պահում այն՝ ընդհանուր օգտագործումներ, օգտագործումներ մեկ հաճախորդի համար, առավելագույն զեղչ, բյուջե։ Ակցիաները կարող են լինել ավտոմատ (կիրառվում են, երբ պայմանները համընկնում են) կամ ձեռքով (ակտիվացվում են կոդով կամ կոճակով)։ Կանոնները որպես տվյալ պահելը՝ տիպավորված պայմաններով և գործողություններով տողեր, կոդի փոխարեն, հենց դա է թույլ տալիս մարքեթինգին աշխատել առանց ծրագրավորողների։

• Տոկոսային՝ 10% զեղչ զամբյուղի կամ ընտրված տողերի վրա, ցանկության դեպքում՝ վերին սահմանով։
• Ֆիքսված՝ 5.00 զեղչ 30.00-ից բարձր պատվերների համար։
• Առաջին պատվեր, ծննդյան օր, լոյալության մակարդակ՝ պայմաններ հաճախորդի, ոչ թե զամբյուղի վրա։
• Նվեր ապրանք կամ անվճար առաքում՝ գործողություններ, որոնք փոխում են տողերը կամ վճարները, ոչ միայն ընդհանուր գումարը։

02Stacking, առաջնահերթություն և բացառիկություն

Stacking-ը նշանակում է մեկ պատվերի վրա մի քանի ակցիա համակցել։ Առանց կանոնների զեղչերը կուտակվում և վնասի են վերածվում։ Գործնական մոդել՝ յուրաքանչյուր ակցիա ունի առաջնահերթություն և stacking ռեժիմ՝ exclusive (ոչնչի հետ չի համակցվում), համակցելի ցանկացածի հետ կամ համակցելի միայն իր խմբի ներսում։ Որոշեք նաև կիրառման հերթականությունը․ տոկոսային զեղչերը սովորաբար կիրառվում են ֆիքսվածներից առաջ, իսկ տողի զեղչերը՝ զամբյուղի զեղչերից առաջ, որովհետև հերթականությունը փոխում է արդյունքը։ Որոշեք՝ զեղչը կիրառվում է այլ զեղչերից առաջ, թե հետո եղած գնի վրա, և երբեք թույլ մի տվեք, որ ընդհանուր գումարն իջնի զրոյից կամ կարգավորված մարժայից ցածր։ Այս կանոնները գրի առեք որպես կարճ աղյուսակ, որը մարքեթինգը հաստատում է․ հետո իրականացրեք հենց այդ աղյուսակը և թեստավորեք այն։

03Լավագույն գին հաճախորդի համար

Երբ մի քանի առաջարկ իրավունք ունի կիրառվելու, բայց բոլորը չեն կարող համակցվել, ո՞րն է հաղթում։ Ամենաբարեհամբույր պատասխանն է՝ այն համակցությունը, որը հաճախորդին ամենացածր ընդհանուր գումարն է տալիս։ Շարժիչը նախ ֆիլտրում է կիրառելի ակցիաները, ապա կառուցում stacking-ի կանոններով թույլատրված վավեր համակցությունները, յուրաքանչյուրը սիմուլյացիա անում զամբյուղի պատճենի վրա և ընտրում ամենաէժան արդյունքը՝ դետերմինիստիկ tie-breaker-ով, օրինակ՝ ավելի բարձր առաջնահերթություն, ապա ավելի հին ակցիա։ Համակցությունների քանակն արագ է աճում, ուստի պահեք այն սահմանափակ․ exclusive առաջարկները կազմում են մեկ տարրից բաղկացած սցենարներ, իսկ համակցելիները սովորաբար greedy կերպով stack են արվում իրենց խմբի ներսում։ Վերադարձրեք ոչ միայն ընդհանուր գումարը, այլև բացատրություն յուրաքանչյուր տողի համար («Ամառային զեղչ −10%»), որը երևում է կտրոնի վրա և հեշտացնում է support-ի հարցերը։

1type Cart = { lines: { id: string; price: number; qty: number }[] };
2type Promo = { id: string; priority: number; exclusive: boolean; apply: (c: Cart) => number };
3 
4// Returns the discount combination with the lowest final total
5export function bestScenario(cart: Cart, eligible: Promo[]) {
6  const subtotal = cart.lines.reduce((s, l) => s + l.price * l.qty, 0);
7  const stackable = eligible.filter((p) => !p.exclusive).sort((a, b) => b.priority - a.priority);
8  const scenarios: Promo[][] = [stackable, ...eligible.filter((p) => p.exclusive).map((p) => [p])];
9 
10  let best = { promos: [] as Promo[], total: subtotal };
11  for (const promos of scenarios) {
12    const discount = promos.reduce((sum, p) => sum + p.apply(cart), 0);
13    const total = Math.max(0, subtotal - discount);
14    if (total < best.total) best = { promos, total };
15  }
16  return best; // ties keep the earlier, higher-priority scenario
17}

04Wallet-ներ, cashback և լոյալության մակարդակներ

Cashback-ը պատվերի տոկոսը վերադարձնում է հաճախորդի wallet՝ որպես խանութի կրեդիտ։ Wallet-ին վերաբերվեք որպես ledger-ի․ երբեք մի պահեք միայն մնացորդը՝ պահեք յուրաքանչյուր մուտք և ելք՝ պատճառով և պատվերի reference-ով, և մնացորդը ստացեք կամ ստուգեք այդ տողերից։ Cashback-ը հաշվեք միայն այն բանից հետո, երբ պատվերն առաքված է կամ վերադարձի պատուհանը փակված է, այլապես մարդիկ գնում են, հավաքում cashback-ը և վերադարձնում ապրանքը։ Wallet-ից ծախսելը checkout-ում վճարման եղանակ է, որը կիրառվում է ակցիաներից հետո։ Լոյալության մակարդակները (օրինակ՝ Bronze, Silver, Gold) պարգևատրում են հաճախորդներին ըստ ծախսի կամ միավորների որոշակի ժամանակահատվածում։ Սահմանեք, թե ինչպես է հաճախորդը բարձրանում, երբ կարող է իջնել և արդյոք կա արտոնյալ ժամանակահատված (grace period)։ Միավորներն ու մնացորդները հաճախ սպառվում են անգործության դեպքում․ ուղարկեք հիշեցում մինչ այդ։

• Ledger-ի տողեր՝ credit, debit, expire, manual adjustment, յուրաքանչյուրը՝ ով և ինչու։
• Աշխատակիցների ձեռքով ճշգրտումները արժանի են audit log-ի, իսկ խոշորները՝ երկրորդ հաստատման։
• Մակարդակները վերահաշվարկեք ժամանակացույցով և սինքրոնացրեք հաճախորդների սեգմենտների հետ։

05Referral-ներ, վաուչերներ և խարդախության ստուգումներ

Referral ծրագիրը պարգևատրում է հաճախորդին ընկերներին հրավիրելու համար․ յուրաքանչյուր օգտատեր ստանում է կոդ կամ հղում, ընկերը գրանցվում է դրանով, և երկուսն էլ պարգև են ստանում ընկերոջ առաջին որակավորող պատվերից հետո։ Հետևեք click-երին և գրանցումներին, իսկ մոբայլ հավելվածների համար օգտագործեք deferred deep link-եր, որպեսզի կոդը պահպանվի հավելվածի տեղադրումից հետո։ Պարգևները հաշվարկեք ուշացված batch job-ով, ոչ թե ակնթարթորեն, որպեսզի կարողանաք չեղարկել վերադարձված պատվերների պարգևները։ Referral-ներն ու վաուչերները չարաշահումներ են գրավում՝ ինքնահրավեր երկրորդ հաշվով, շատ հաշիվներ մեկ հեռախոսի կամ քարտի վրա, կոդեր, որոնք կիսվում են կուպոնների կայքերում։ Պարզ ստուգումները բռնում են դրա մեծ մասը՝ նույն սարքը, հեռախոսը, քարտի fingerprint-ը կամ հասցեն, ինչ հրավիրողինը, վերադարձված պատվեր, կարճ ժամանակում մեկ կոդով չափազանց շատ գրանցումներ։ Վաուչերները պետք է լինեն պատահական, բավական երկար՝ գուշակելուն դիմանալու համար, rate-limited և մեկանգամյա, երբ արժեք են կրում։

06Engine-ի ճարտարապետություն. մաքուր pricing pipeline

Ամենահուսալի promotion engine-ները pure function-ներ են. տրված զամբյուղի, հաճախորդի context-ի, ժամանակի և ակտիվ ակցիաների ցուցակի դեպքում դրանք վերադարձնում են գնահատված զամբյուղ և բացատրություն՝ առանց database-ում որևէ բան գրելու։ Դա հեշտացնում է դրանց թեստավորումը ճշգրիտ գումարներով, դարձնում է անվտանգ դրանց գործարկումը զամբյուղի յուրաքանչյուր փոփոխության ժամանակ և ապահովում նույն արդյունքը զամբյուղի էջում, checkout-ում և admin preview-ներում։ Pipeline-ը կառուցեք փուլերով. բեռնեք թեկնածու ակցիաները (նախապես ֆիլտրված ըստ ամսաթվի, ալիքի և կարգավիճակի՝ index-ով), գնահատեք պայմանները, կառուցեք scenario-ներ, կիրառեք action-ները զամբյուղի պատճենի վրա, ընտրեք լավագույնը և ստացեք տողի մակարդակի adjustment-ներ։ Side effect-ները՝ օգտագործման հաշվարկը, voucher-ի դեբետը, cashback-ի կրեդիտը, տեղի են ունենում ավելի ուշ, միայն երբ պատվերը ստեղծվում կամ ավարտվում է, պատվերի transaction-ի ներսում։

1type Ctx = { now: Date; customerId?: string; segment: string[]; channel: "web" | "app" };
2type Adjustment = { lineId?: string; promoId: string; amount: number; label: string };
3 
4// Pure: same input → same output, no I/O
5export function priceCart(cart: Cart, ctx: Ctx, promos: Promo[]) {
6  const eligible = promos.filter((p) => p.isActive(ctx.now) && p.matches(cart, ctx));
7  const best = bestScenario(cart, eligible);
8  const adjustments: Adjustment[] = best.promos.flatMap((p) => p.adjustments(cart));
9  return { total: best.total, adjustments };
10}

07Օգտագործման սահմանափակումներ concurrency-ի պայմաններում

«Առաջին 500 հաճախորդները» և «մեկ օգտագործում յուրաքանչյուր հաճախորդի համար» պարզ են հնչում, մինչև 2,000 մարդ նույն րոպեին checkout չանի։ Օգտագործումները SELECT COUNT-ով հաշվելը և հետո insert անելը race condition է. բոլորը տեսնում են 499։ Սահմանափակումները կիրառեք database-ի միջոցով։ Գլոբալ սահմանի համար պահեք counter տող և ավելացրեք այն պայմանականորեն (UPDATE promotions SET used = used + 1 WHERE id = :id AND used < max_uses) պատվերի transaction-ում։ Յուրաքանչյուր հաճախորդի սահմանի համար insert արեք redemption տող՝ (promotion_id, customer_id)-ի վրա unique constraint-ով։ Ազատեք օգտագործումը, եթե պատվերը չեղարկվում է մինչև վճարումը։ Բյուջեի սահմաններն աշխատում են նույն կերպ՝ քանակների փոխարեն գումարներով։ Նորից վալիդացրեք checkout-ում և ընդունեք, որ զամբյուղի էջը կարող է ցույց տալ ակցիա, որը մեկ վայրկյան անց արդեն չկա. հստակ տեղեկացրեք հաճախորդին։

08Ինչպես չափել՝ արդյոք ակցիան աշխատում է

Ակցիան ծախս է, և հարցն այն է, թե ինչ է այն գնել։ Յուրաքանչյուր ակցիայի համար հետևեք. պատվերներ, տրված զեղչ, եկամուտ, մարժա զեղչից հետո, նոր և վերադարձող հաճախորդներ, redemption rate։ Հում թվերը մոլորեցնում են, որովհետև շատ հաճախորդներ ամեն դեպքում կգնեին։ Ազնիվ չափանիշը incrementality-ն է. համեմատեք պատահականորեն ընտրված խումբը, որը ստանում է առաջարկը, holdout խմբի հետ, որը չի ստանում, և նայեք պատվերների ու մարժայի տարբերությանը։ Նույնիսկ newsletter-ի կուպոնի պարզ 90/10 բաժանումը ավելի լավ պատասխաններ է տալիս, քան ցանկացած dashboard։ Loyalty ծրագրերի դեպքում հետևեք կրկնակի գնումների հաճախականությանը և պատվերների միջև ընկած ժամանակին՝ ըստ tier-ի, ինչպես նաև չօգտագործված միավորների կամ wallet-ի բալանսների պարտավորությանը, որը ֆինանսական բաժինը կարող է ստիպված լինել դիտարկել որպես հետաձգված ծախս։

• Հաշվետվությունների համար պատվերի տողերի վրա պահեք կիրառված ակցիաների ID-ները և գումարները։
• Զեղչի ծախսը ներկայացրեք որպես եկամտի տոկոս՝ ըստ յուրաքանչյուր արշավի։
• Ավտոմատ առաջարկների համար, ինչպիսիք են win-back կուպոնները, պահեք holdout խումբ։

09Միավորների և wallet-ի հաշվառման եզրային դեպքեր

Ledger-ի վրա հիմնված wallet-ները առաջացնում են եզրային դեպքեր, որոնք արժե նախապես որոշել։ Ժամկետի ավարտ. first-in-first-out ծախսման դեպքում դեբետները նախ սպառում են ամենահին կրեդիտները, ուստի expiry job-ը ճշգրիտ գիտի, թե յուրաքանչյուր կրեդիտից որքան է մնացել. դա էժան դարձնելու համար պահեք մնացորդային գումարները յուրաքանչյուր credit lot-ի համար։ Մասնակի refund-ներ. եթե մասամբ wallet-ի կրեդիտով վճարված պատվերը մասամբ refund է արվում, որոշեք՝ նախ կրեդի՞տը, թե՞ քարտին է վերադարձվում գումարը, և cashback-ը չեղարկեք համամասնորեն։ Concurrency. դեբետները պետք է lock անեն հաճախորդի wallet-ի տողը կամ օգտագործեն պայմանական update, որպեսզի երկու զուգահեռ checkout չկարողանան ծախսել նույն բալանսը։ Արժույթ. wallet-ը պետք է պահի մեկ արժույթ։ Իրավական տեսանկյունից որոշ երկրներում store credit-ը կամ միավորները կարող են համարվել stored value կամ e-money՝ սպառողական և հաշվապահական կանոններով, ուստի ստուգեք, նախքան հաճախորդներին թույլ կտաք իրական գումարով լիցքավորել բալանսը։