SaaS និងក្រុមផលិតផល
ផលិតផលរបស់អ្នកដឹងពីអ្វីដែលឧបករណ៍ទីផ្សារណាមួយមិនអាចឃើញបាន
អ្នកណាបញ្ចប់ onboarding និងអ្នកណាគាំងនៅជំហានទីបី។ អ្នកណាបានអញ្ជើញមិត្តរួមការងារ។ អ្នកណាដល់ដែនកំណត់ពីរដងក្នុងសប្តាហ៍នេះ។ អ្នកណាមិនបានបើកវារយៈពេលពីរសប្តាហ៍។ នីមួយៗក្នុងចំណោមទាំងនោះជា trigger ល្អជាងអ្វីដែលបានមកពីការបើកអ៊ីមែល ហើយទាំងអស់គឺឆ្ងាយត្រឹមពីរបន្ទាត់កូដប៉ុណ្ណោះ។
ព្រឹត្តិការណ៍គឺជាការតភ្ជាប់ទាំងមូល
POST /v1/events ជាមួយ token របស់អ្នក៖ ឈ្មោះដែលអ្នកជ្រើសរើស ទំនាក់ទំនងមួយ payload មួយ idempotency key មួយ។ នោះគឺជាការតភ្ជាប់ទាំងមូល។ គ្មាន SDK ត្រូវធ្វើឲ្យទាន់សម័យ គ្មានអេក្រង់ mapping ហើយគ្មានបញ្ជីពាក្យរបស់យើងដែលអ្នកត្រូវបកប្រែផលិតផលរបស់អ្នកទៅជាវា។
ព្រឹត្តិការណ៍នីមួយៗធ្លាក់ចុះលើកំណត់ហេតុ append-only របស់ទំនាក់ទំនង ហើយពីទីនោះវាជាបីយ៉ាងក្នុងពេលតែមួយ។ Trigger ដូច្នេះ funnel ចាប់ផ្តើមពេលវាមកដល់។ Predicate ដូច្នេះ segment អាចនិយាយថា "បានធ្វើវាក្នុងរយៈពេលសូន្យថ្ងៃចុងក្រោយ" ឬដែលមានប្រយោជន៍ជាង "មិនបានធ្វើ"។ និង Goal ដូច្នេះលំដាប់បញ្ចប់នៅពេលដែលអ្នកណាម្នាក់ធ្វើអ្វីដែលវាកំពុងជំរុញពួកគេ។
ចំណុចទីបីនោះគឺជាអ្វីដែលធ្វើឲ្យសារ lifecycle ទទួលបានបានយ៉ាងស្រួល។ ការជំរុញឲ្យបញ្ចប់ការដំឡើងគណនីគួរតែឈប់មាននៅទីបញ្ចប់នៃការដំឡើងគណនី ហើយក្នុងឧបករណ៍ភាគច្រើនវាមិនដូច្នោះទេ ព្រោះលំដាប់និងផលិតផលមិននិយាយទំនាក់ទំនងគ្នាទេ។
- ⚡គន្លឹះ
api_event—signup.completed, ផែនfree។ - 2ផ្ញើអ៊ីមែលរឿងតែមួយដែលត្រូវធ្វើជាដំបូង។ មិនមែនជាការធ្វើដំណើរមើលលក្ខណៈពិសេសដប់មួយទេ។
- 3រង់ចាំ ២ ថ្ងៃ
wake_atលើដំណើរការ។ គ្មានអ្វីជាប់គាំង គ្មានអ្វីត្រូវដោះស្រាយប្រសិនបើអ្នកសរសេរវាឡើងវិញថ្ងៃស្អែក។ - ?លក្ខខណ្ឌ
project.createdបានមកដល់ឬនៅ? ទេ → សាខាជួយ។ បាទ/ចាស → goal ខាងក្រោម។ - 4សាខាជួយសារមួយ ផ្តល់ជូនអ្វីជាក់លាក់ដែលពួកគេមិនបានធ្វើ។ បន្ទាប់មកការរង់ចាំទីពីរ។
- 5គោលដៅ
project.createdមកដល់។ ដំណើរការបញ្ចប់។ មិនមានអ៊ីមែលណែនាំបន្ថែមទៀតឡើយ សម្រាប់មនុស្សនេះជារៀងរហូត។
ឈ្មោះព្រឹត្តិការណ៍របស់អ្នកនិយមន័យរបស់អ្នកអំពី 'សកម្ម'
ផ្លូវ funnel ប្រាំ
វដ្តជីវិត តាមលំដាប់ដែលវាកើតឡើងពិតប្រាកដ
១ · ការធ្វើឱ្យសកម្ម
ការបង្កើត៖ ការចុះឈ្មោះ។ សារពីរ ឬបី មួយម្នាក់ៗអំពីសកម្មភាពតែមួយ មួយម្នាក់ៗមានគោលដៅដែលបញ្ចប់លំដាប់នៅពេលសកម្មភាពនោះកើតឡើង។ នេះជាផ្លូវ funnel ដែលមានតម្លៃបំផុតដែលអ្នកនឹងបង្កើត និងជាផ្លូវដែលសម្រេចចិត្តសរសេរឡើងវិញបីដងបំផុត។
២ · ការគាំង
ការបង្កើត៖ segment_enter — បានចុះឈ្មោះ ប៉ុន្តែគ្មានព្រឹត្តិការណ៍សំខាន់ក្នុងរយៈពេលប្រាំពីរថ្ងៃ។ សារមួយដែលសួរជាជាងប្រាប់ និងមួយទៀតដែលផ្តល់អ្វីមួយជាក់លាក់។ បន្ទាប់មកឈប់។ សារទីបួនទៅកាន់អ្នកដែលបានមិនអើពើលើសារបី គឺជាសារទៅកាន់គ្មាននរណាម្នាក់។
៣ · ពេលវេលានៃការពង្រីក
ការបង្កើត៖ ព្រឹត្តិការណ៍ដែលបញ្ជាក់ថាពួកគេកំពុងទទួលបានតម្លៃ — បានដល់ដែនកំណត់ បានអញ្ជើញសហការីទីបី បាននាំចេញលើកទីពីរ។ នេះជាពេលវេលាតែមួយគត់ដែលសារបន្ទាប់កម្រិត (upgrade) ទទួលបានការស្វាគមន៍ ហើយវាជាពេលវេលាដែលផលិតផលរបស់អ្នកអាចបញ្ជាក់បានយ៉ាងជាក់លាក់។
៤ · ការបន្តសេវា និងការទារប្រាក់
ការបង្កើត៖ date_field មុនពេលបន្តសេវា ឬព្រឹត្តិការណ៍ការទូទាត់។ ការជូនដំណឹង ការរំលឹក និង — ប្រសិនបើការទូទាត់បរាជ័យ — លំដាប់ខ្លីដែលឈប់ភ្លាមៗនៅពេលជោគជ័យ។ ថ្នាក់គោលដៅមិនអាចខ្វះបានឡើយក្នុងការទារប្រាក់។ វាជាការបែងចែករវាងការរំលឹក និងការរំខាន។
៥ · ទាញត្រឡប់មកវិញ
ការធ្យូង (Trigger)៖ segment_enter — បានបោះបង់ ឬអសកម្មរយៈពេលធូរសិបថ្ងៃ។ សារពីរ ដោយស្មារតីត្រង់ បន្ទាប់មកដាក់ស្លាក ហើយស្ងាត់។ អ្វីដែលបានផ្លាស់ប្តូរតាំងពីពួកគេចេញទៅ គឺជាសារល្អជាងការបញ្ចុះតម្លៃ។
និងផ្លូវផ្ទៃក្នុង
notify_team ប្រាប់មនុស្សម្នាក់នៅពេលគណនីដែលសម្រេចចិត្តត្រូវការមនុស្សឆ្លងកាត់ព្រំដែន។ ផ្លូវ funnel មិនចាំបាច់បញ្ចប់ដោយអ៊ីមែលទៅកាន់អតិថិជនឡើយ។ ពេលខ្លះសកម្មភាពត្រឹមត្រូវគឺប្រាប់មនុស្សនៅផ្នែករបស់អ្នកឱ្យទូរស័ព្ទ។
គ្មាននរណាម្នាក់បោះបង់ដោយចេតនាឡើយ។ ពួកគេគ្រាន់តែឈប់បើកវា។
ហេតុអ្វីអ្នកអភិវឌ្ឍន៍អាចចូលចិត្តវាពិតប្រាកដ
ផ្នែកដែលសំខាន់នៅពេលអ្នកជាអ្នកធ្វើការតភ្ជាប់
គ្មាន endpoint ឯកជនឡើយ
រាល់អេក្រង់អាចបង្កើតបានពី API សាធារណៈ ព្រោះគ្មានប្រភេទផ្សេងទៀតឡើយ។ ប្រសិនបើអ្នកចង់បង្កប់របាយការណ៍កម្មវិធីតែងតែងនៅក្នុង admin របស់អ្នក គ្មានអ្វីរារាំងអ្នកឡើយ ហើយគ្មានអ្វីត្រូវ reverse-engineer ឡើយ។
កូនសោ idempotency នៅគ្រប់ទីកន្លែង
នៅលើរាល់ route ដែលផ្លាស់ប្តូរទិន្នន័យ។ តក្កវិជ្ជាព្យាយាមឡើងវិញរបស់អ្នក ជួរ at-least-once របស់អ្នក និងបណ្តាញមិនស្ថិរភាពរបស់អ្នក ទាំងអស់ក្លាយជាបញ្ហារបស់អ្នកដទៃ — ជាក់លាក់ ជាបញ្ហារបស់ unique index មួយ។
សម្របសម្រួលមុនពេលដាក់ឱ្យប្រើ
POST /v1/simulate សាកល្បងដំណើរការ contact ម្នាក់ឆ្លងកាត់ funnel មួយ ហើយត្រឡប់ផ្លូវ និងរាល់សារដែលវានឹងផ្ញើ។ ដាក់វាក្នុង CI បានបើអ្នកចង់បាន៖ funnel គឺជាក្រាហ្វ ហើយក្រាហ្វអាចសាកល្បងបាន។
MCP server មួយ
ចុច agent ទៅ /mcp ហើយឱ្យវាសរសេរ និងពិនិត្យ funnel។ ឧបករណ៍ដែលអាចផ្ញើបានត្រូវការការបញ្ជាក់យ៉ាងច្បាស់ ហើយត្រូវកំណត់ដោយ quota ដូច្នេះ prompt ដែលអានខុសមិនអាចក្លាយជាអ៊ីមែលប្រាំម៉ឺនឡើយ។
Webhooks ចេញ
ចុះហត្ថលេខា ព្យាយាមឡើងវិញដោយ backoff យ៉ាងតិចម្តង។ បញ្ជីពាក្យព្រឹត្តិការណ៍ដូចគ្នាដែលរបាយការណ៍ប្រើ ដូច្នេះ warehouse និង dashboard របស់អ្នកមិនជំទាស់គ្នាអំពីអត្ថន័យនៃ "delivered" ឡើយ។
ការលុបចោលដែលពិតជាទៅដល់
សំណើលុបចោលដក contact និងប្រវត្តិសាររបស់ពួកគេចេញនៅទីនេះ ហើយផ្សព្វផ្សាយទៅសេវាបងប្អូនទាំងអស់ដែលកាន់កាប់ចម្លង។ សំណើមួយ លទ្ធផលមួយ និងអ្វីមួយដែលអ្នកអាចចង្អុលបង្ហាញនៅពេលត្រូវបានសួរ។
ព្រំដែនស្ថិតនៅទីណា
ClickSomo កាន់កាប់បញ្ជីអ៊ីមែល និងអ្វីដែលបញ្ជីនោះបានធ្វើ។ វាមិនមែនជាមូលដ្ឋានទិន្នន័យអ្នកប្រើរបស់អ្នកឡើយ ហើយក៏មិនព្យាយាមក្លាយជាដែរ៖ contact មិនដែលមាន credential ឡើយ មិនដែលចូលឡើយ ហើយមិនដែលក្លាយជាគណនីឡើយ។ អ្នកប្រើរបស់អ្នករស់នៅក្នុងផលិតផលរបស់អ្នក។ contact រស់នៅទីនេះ ហើយទាំងពីរត្រូវភ្ជាប់ដោយអាសយដ្ឋានអ៊ីមែល និងព្រឹត្តិការណ៍ដែលអ្នកជ្រើសរើសផ្ញើ។
ការបែងចែកនេះជាការសម្រេចចិត្តដោយចេតនា ហើយវាជាមូលដ្ឋានដែលម៉ូដែលការយល់ព្រមដំណើរការ។ អ្នកជា data controller សម្រាប់អ្នកប្រើរបស់អ្នក។ យើងដំណើរការជំនួសអ្នក។ ការរចនាដែលឧបករណ៍ទីផ្សារស្ងាត់ៗក្លាយជាកន្លែងផ្ទុកអត្តសញ្ញាណ គឺជាការរចនាដែលមិនអាចដោះស្រាយបាននៅពេលក្រោយឡើយ ហើយវាជាការបរាជ័យដែលការរចនានេះត្រូវបានបង្កើតឡើងដើម្បីជៀសវាង។
កំណែអនុវត្តជាក់ស្តែង៖ ផ្ញើព្រឹត្តិការណ៍ ផ្ញើ attribute ដែលអ្នកចង់បែងចែកតាម ហើយរក្សាទាំងអស់ដែលនៅសល់នៅកន្លែងរបស់វា។ ប្រសិនបើអ្នករកឃើញខ្លួនកំពុងរុញ schema ទាំងមូលរបស់អ្នកចូលមកទីនេះ ផ្នែកដែលអ្នកព្យាយាមបង្កើតប្រហែលជាសំណួរ (query) ក្នុងមូលដ្ឋានទិន្នន័យរបស់អ្នក ដែលគួរមកដល់ជា attribute boolean តែមួយជំនួសវិញ។