clickSomo
បើក ClickSomo

ទំនាក់ទំនង និងការយល់ព្រម

បញ្ជីដែលអ្នកអាចការពារបាន មិនមែនគ្រាន់តែបញ្ជីដែលអ្នកមានឡើយ

នរណាម្នាក់ក៏អាចកាន់អាសយដ្ឋានអ៊ីមែលមួយម៉ឺនបានដែរ។ សំណួរដែលសំខាន់ — ដែលស្ថាប័នរដ្ឋប្បវេណី អ្នកផ្តល់សេវា និងសតិសម្បជញ្ញៈរបស់អ្នកសុទ្ធតែសួរជាពាក្យខុសៗគ្នា — គឺថាអាសយដ្ឋាននីមួយៗមកពីណា ហើយលើមូលដ្ឋានអ្វីដែលអ្នកអាចសរសេរទៅវាបាន។ ClickSomo ធ្វើឱ្យវាក្លាយជាព័ត៌មានដែលបានរក្សាទុក មិនមែនអ្វីដែលអ្នកត្រូវស្ថាបនាឡើងវិញឡើយ។

អត្តសញ្ញាណគឺជាអាសយដ្ឋានអ៊ីមែល

ទំនាក់ទំនងម្នាក់ក្នុងមួយអាសយដ្ឋាន ក្នុងមួយគម្រោង ដែលបង្ខំដោយមូលដ្ឋានទិន្នន័យ មិនមែនដោយការសង្ឃឹមទេ។ អាសយដ្ឋានត្រូវធ្វើឲ្យជាទម្រង់ជាក់លាក់ពេលសរសេរ មិនមែនពេលអានទេ — បើធ្វើនៅពេលអាន ការរឹតបន្តឹងនោះគ្រាន់តែជាការតុបតែង ដែលអនុញ្ញាតឲ្យ Anna@ និង anna@ ចូលទាំងពីរ។

លេខទូរស័ព្ទត្រូវរក្សាទុកក្នុងទម្រង់ E.164 ប្រសិនបើមាន ប៉ុន្តែលេខទូរស័ព្ទគឺជាលក្ខណៈសម្បត្តិ មិនមែនអត្តសញ្ញាណទេ។ មិនមានក្រាហ្វស្វែងរកអត្តសញ្ញាណ មិនមានពិធីបញ្ចូលគ្នា និងមិនមានបញ្ជីត្រួតពិនិត្យនៃការបញ្ចូលគ្នាទេ ព្រោះទំនាក់ទំនងនីមួយៗនៅទីនេះមកដល់តាមឆានែលដែលមានអាសយដ្ឋានរួចហើយ៖ ការនាំចូល ទម្រង់បែបបទ ការជាវ ឬកូដរបស់អ្នក។

ឈ្មោះត្រូវរក្សាទុកទាំងមូល

display_name ត្រូវរក្សាទុកដូចដែលបានផ្តល់មកជាក់លាក់ ហើយមិនដែលបំបែកជាផ្នែកៗទេ។ ការបំបែកឈ្មោះគឺជាប្រភពនៃកំហុស — "van der Berg", "Kim Min-jun", ឈ្មោះតែមួយពាក្យ, ចំណងជើង និងទម្រង់តម្រៀបទាំងឡាយដែលមិនមែនតាមបែបអង់គ្លេស — ហើយការបំបែកខុសនឹងបង្ហាញក្នុងស្លាកបញ្ចូលជា "Dear van," ដែលអាក្រក់ជាងការមិនប្រើឈ្មោះផ្ទាល់ខ្លួនទាំងស្រុង។

ផ្នែករចនាសម្ព័ន្ធមានតែសម្រាប់ប្រភពដែលផ្តល់វាដាច់ដោយឡែករួចហើយប៉ុណ្ណោះ។ គ្មានអ្វីធ្វើឲ្យវាកើតឡើងដោយខ្លួនឯងទេ។ ហើយឈ្មោះដែលនរណាម្នាក់បានសរសេរដោយខ្លួនឯង មិនដែលត្រូវសរសេរជាន់ដោយឯកសារ CSV ក្រោយមកដែលបានឃើញខុសពីនោះទេ ព្រោះការសរសេរចុងក្រោយឈ្នះ នឹងអនុញ្ញាតឲ្យការនាំចូលដែលមិនប្រុងប្រយ័ត្នបំផុតឈ្នះ។

ទំនាក់ទំនងមួយអ្វីដែលត្រូវរក្សាទុក
  • 1អត្តសញ្ញាណអ៊ីមែល ដែលបានធ្វើឲ្យជាទម្រង់ជាក់លាក់។ មិនដូចគ្នាក្នុងគម្រោង។
  • 2ឈ្មោះរក្សាទុកទាំងមូល។ first_name ត្រូវគណនាពេលបង្ហាញ មិនរក្សាទុកទេ។
  • 3លក្ខណៈសម្បត្តិអ្វីក៏បានដែលអ្នកចង់បាន ជា JSON។ ជារបស់អ្នក ហើយអាចបញ្ចូលបានជា attrs.*។
  • 4ស្លាក និងបញ្ជីស្លាកគឺជាធាតុសំខាន់ ហើយរស់នៅក្នុងឃ្លាំងតែមួយ; បញ្ជីគឺជាសមាជិកភាពដែលបានកំណត់ច្បាស់លាស់។
  • 5ការយល់ព្រមជួរដេកមួយក្នុងមួយឆានែល ជាមួយមូលដ្ឋានច្បាប់ និងភស្តុតាងរបស់វា។
  • 6ព្រឹត្តិការណ៍កំណត់ត្រាបន្ថែមតែប៉ុណ្ណោះនៃអ្វីគ្រប់យ៉ាងដែលបុគ្គលនេះបានធ្វើ។ តារាងដែលផលិតផលពឹងផ្អែកលើវា។
  • ×មិនដែលគ្មានពាក្យសម្ងាត់ គ្មាន hash គ្មានសេសស្យុង គ្មាន API key។ ជួរឈរដែលផ្ទៀងផ្ទាត់នរណាម្នាក់ នឹងជាលទ្ធផលអាក្រក់ មិនមែនលក្ខណៈពិសេសទេ។

កំណត់សម្រតែអ្នកប្រើប្រាស់ និងគម្រោង ទាំងពីរ

បញ្ជីការយល់ព្រម

ការគ្មានវត្តមាន មិនមែនជាការអនុញ្ញាតទេ

ជួរដេកមួយក្នុងមួយទំនាក់ទំនង ក្នុងមួយឆានែល — អ៊ីមែល, SMS, សំបុត្រ, push — នីមួយៗផ្ទុកស្ថានភាពមួយ, មូលដ្ឋានច្បាប់, ប្រភព, ភស្តុតាង, ពេលវេលា និងស្រុកសិទ្ធិ។ ទំនាក់ទំនងដែលគ្មានជួរដេកមូលដ្ឋានសម្រាប់ឆានែលណាមួយ មិនអាចត្រូវបានផ្ញើអ្វីតាមឆានែលនោះបានទេ។ មិនមែន "ត្រូវបានសម្គាល់" ទេ។ មិនអាច។

consent

នរណាម្នាក់បានសួរដោយសកម្មភាព។ ការដាក់ស្នើទម្រង់ជាមួយភស្តុតាងដែលបានរក្សាទុក, double opt-in, ប្រអប់ធីកដែលពួកគេធីកដោយខ្លួនឯង។ នេះជាមូលដ្ឋានខ្លាំងបំផុត ហើយជាមូលដ្ឋានតែមួយដែលទម្រង់អាចបង្កើតបាន។

legitimate_interest

ល្អបំផុតដែលការនាំចូល CSV អាចទទួលបាន។ សៀវភៅបញ្ជីមិនអាចចងចាំការយល់ព្រមរបស់នរណាម្នាក់បានទេ ដូច្នេះវាមិនដែលត្រូវអនុញ្ញាតឲ្យអះអាងថាពួកគេបានយល់ព្រមទេ — ហើយការឡើងទំនើបឯកសារដូចគ្នាមិនធ្វើឲ្យវាកាន់តែល្អទេ។

contract

អ្នកសរសេរទៅពួកគេ ព្រោះអ្វីមួយដែលអ្នកទាំងពីរជាភាគី។ ការរំលឹកសេវាកម្ម, សេចក្តីជូនដំណឹងនៃការបន្ត, អ្វីដែលពួកគេនឹងមិនរំភើបប្រសិនបើមិនបានទទួល។

មុនពេលយុទ្ធនាការផ្ញើ អ្នកឃើញ សមាសភាពមូលដ្ឋាននៃទស្សនិជនរបស់វា៖ មានប៉ុន្មាននាក់ដែលបានសួរ, មានប៉ុន្មានដែលអ្នកទៅដល់ក្រោមចំណាប់អារម្មណ៍ស្របច្បាប់, និងមានប៉ុន្មាននៅទីនោះព្រោះកិច្ចសន្យា។ វាជាលេខមួយដែលបានបញ្ឈប់ការផ្ញើអាក្រក់ច្រើនជាងរាល់បដាព្រមានណាមួយដែលធ្លាប់សរសេរ។

ហេតុអ្វីបានជាវាម៉ត់ចត់ជាងតម្រូវការសម្រាប់អ្នក៖ ពិតទេ វាមិនមែនអំពីអ្នកទេ។ កេរ្តិ៍ឈ្មោះនៃការផ្ញើជាប្រភេទច្រើន គឺជាធនធានរួម ហើយបញ្ជីមិនប្រុងប្រយ័ត្នមួយ ធ្វើឲ្យអនាម័យអាក្រក់សម្រាប់អ្នកផ្ញើទាំងអស់ពីហេដ្ឋារចនាសម្ព័ន្ធដូចគ្នា។ អត្រាបណ្តាសា និងការបរាជ័យក្នុងមួយអ្នកប្រើប្រាស់ ត្រូវបានតាមដាន ហើយគណនីដែលអត្រាលើសពីកម្រិត ត្រូវបានកំណត់ល្បឿននៅទីនេះ — មុនពេលអ្នកផ្តល់សេវាធ្វើវាដល់អ្នកទាំងអស់ក្នុងពេលតែមួយ។

នៅពីក្រោយរាល់ជួរដេកក្នុងបញ្ជី មាននរណាម្នាក់បានព្រមព្រៀង។

ផ្លូវចូលបួន

រាល់ផ្លូវចូលទៅក្នុងបញ្ជីរបស់អ្នក គឺជាអ្នកផ្ទាល់

គ្មានផ្លូវ ingest តាមរយៈ service-token និងគ្មានផលិតផលបងប្អូនសរសេរចូលទៅក្នុងទំនាក់ទំនងរបស់អ្នកដោយស្ងាត់ៗទេ។

ការនាំចូល CSV

តម្រឹមជួរឈរម្តងមួយៗ ធ្វើឲ្យជាទម្រង់ពេលសរសេរ ពិនិត្យ MX ដើម្បីចាប់ដូមេងុត និងដូមេសរសេរខុស មុនពេលវាបរាជ័យជារៀងរហូត ហើយទទួលបានជាមួយមូលដ្ឋានដែលអ្នកកំណត់។

ទម្រង់ ClickSomo

បង្ហាញពីឯកសារដូចគ្នា ជាមួយការផ្ទៀងផ្ទាត់, honeypot និងការកំណត់អត្រា។ ការដាក់ស្នើគឺជាផ្លូវតែមួយដែលអាចបង្កើត consent បានយ៉ាងស្របច្បាប់ ព្រោះវាជាផ្លូវតែមួយដែលបុគ្គលមានវត្តមាន។

ទំព័រដែលអ្នកបានបង្កើតក្នុង dash-b

អ្នករចនាដាសបូរដ៍បោះពុម្ពទំព័រ; ទម្រង់នៅលើទំព័រមួយក្នុងនោះ ដាក់ស្នើទីនេះជាមួយព័ត៌មានសម្ងាត់របស់អ្នក។ ការផ្ទៀងផ្ទាត់ដូចគ្នា ការគ្រប់គ្រងការយល់ព្រមដូចគ្នា គ្មានការតភ្ជាប់ទីពីរត្រូវថែទាំទេ។

API សាធារណៈ

POST /v1/contacts ជាមួយ token របស់អ្នក, upsert semantics, idempotency key ត្រូវគោរព។ កម្មវិធីរបស់អ្នកធ្លាប់ដឹងរួចហើយថានរណាបានចុះឈ្មោះ; នេះជាផ្លូវខ្លីបំផុតពីការពិតនោះ ទៅកាន់ funnel មួយ។

សេកម៉ង់គឺជាលក្ខខណ្ឌបញ្ជាក់ ដែលត្រូវបានចងក្រង

សេកម៉ង់គឺជាដើមលក្ខខណ្ឌបញ្ជាក់ដែលបានរក្សាទុក លើវាលទំនាក់ទំនង គុណលក្ខណៈ ស្លាក ការជាសមាជិកបញ្ជី និងឥរិយាបថ ដែលត្រូវបានចងក្រងទៅជា SQL និងរក្សាទុកក្នុងឃ្លាំងសម្ងាត់ជាមួយចំនួនរាប់។ ប្រតិបត្តិករទាំងនោះជាប្រតិបត្តិករធម្មតា — ស្មើ មិនស្មើ នៅក្នុង មិននៅក្នុង ចាប់ផ្តើមដោយ បញ្ចប់ដោយ មានផ្ទុក មិនមានផ្ទុក — ដែលផ្សំគ្នាដោយ and, or និង not តាមជម្រៅដែលអ្នកត្រូវការ។

សូមមើលជាមុនសិនមុនពេលប្រើវា។ Endpoint ត្រឡប់ទំនាក់ទំនងពិតមកវិញ ដូច្នេះសំណួរ "នរណាដែលពិតជានៅក្នុងនេះ" អ្នកឆ្លើយដោយការមើល មិនមែនដោយផ្ញើរួចរកឃើញទេ។

សេកម៉ង់បន្ទាប់មកធ្វើការពីរយ៉ាង៖ ជាទស្សនិជនសម្រាប់យុទ្ធនាការ ជាលក្ខខណ្ឌលើម៉ាក់ផ្នែក funnel និងជាការកត់សុំដោយខ្លួនវាផ្ទាល់ — segment_enter ចាប់ផ្តើមការដំណើរការនៅពេលដែលនរណាម្នាក់ក្លាយជាមានសិទ្ធិ។

អតិថិជនទៀងទាត់ស្ងាត់ៗការមើលសេកម៉ង់ជាមុន · 412
  • 1ស្លាកtags contains "regular"
  • 2គុណលក្ខណៈattrs.total_orders >= 3 — វាលរបស់អ្នក ឈ្មោះរបស់អ្នកសម្រាប់វា។
  • 3អាកប្បកិរិយាមិនមានព្រឹត្តិការណ៍ order.paid ក្នុងរយៈពេល 90 ថ្ងៃចុងក្រោយ។
  • 4ការយល់ព្រមមូលដ្ឋានអ៊ីមែលដែលអាចប្រើបាន។ ទំនាក់ទំនងដែលគ្មានវាមិនត្រូវបានរាប់បញ្ចូលក្នុងចំនួនទេ ព្រោះពួកគេមិនអាចត្រូវបានផ្ញើទៅ anyway។
  • iមើលជាមុនទំនាក់ទំនង 412 ត្រូវបានរាយ។ រាប់ឡើងវិញពេលផ្ញើ ព្រោះសេកម៉ង់គឺជាសំណួរ មិនមែនរូបភាពថេរទេ។

ចងក្រងទៅជា SQLចំនួនរក្សាទុកក្នុងឃ្លាំង ចម្លើយទាន់ពេល

ការទប់ស្កាត់ និងពេលណាដែលពិនិត្យ

ការទប់ស្កាត់មានលក្ខណៈតាមគម្រោង និងសកល៖ អ៊ីមែល bounce រឹង ការតវ៉ា ការលុបចោលការជាវ ការបញ្ចូលដោយដៃ និងអាសយដ្ឋាន role។ ពួកវាត្រូវបានពិនិត្យ នៅពេលផ្ញើ ហើយបន្ទាប់មកពិនិត្យម្តងទៀតនៅក្នុងសេវាផ្ញើសារខ្លួនវា។

ពាក្យទីពីរនោះហើយដែលធ្វើការ។ Funnel ដែលមានការរង់ចាំ 3 ថ្ងៃ មានបង្អួច 3 ថ្ងៃដែលនរណាម្នាក់អាចលុបចោលការជាវ ហើយប្រព័ន្ធដែលពិនិត្យការទប់ស្កាត់ពេលសារត្រូវបានដាក់ជួរ នឹងផ្ញើអ៊ីមែលទៅពួកគេដែរ។ ការពិនិត្យនៅពេលផ្ញើគឺជាភាពខុសគ្នារវាងការគោរពការលុបចោលការជាវ និងការតែកត់ត្រាវាប៉ុណ្ណោះ។

ការលុបចោលដំណើរការដូចគ្នា៖ សំណើលុបចោលដកទំនាក់ទំនង និងប្រវត្តិសាររបស់ពួកគេចេញនៅទីនេះ ហើយទៅដល់សេវាបង្អួចទាំងអស់ដែលកាន់កាប់ចម្លង តាមរយៈផ្លូវខាងក្នុងដូចគ្នាដែលគ្រួសារទាំងមូលប្រើ។ មានកន្លែងតែមួយដើម្បីសុំ និងអ្វីមួយដែលកើតឡើងតែមួយ។