Push შეტყობინებები მობილურ აპში: სწორი scope
Push შეტყობინებების დაკვეთის ჩარჩო: trigger, თანხმობა, მიმღები, ტექსტი, უარი, fallback და მიღების ტესტი.
Push შეტყობინება კონკრეტულ მოვლენას უნდა მიებას: ვინ იღებს მას, როდის სჭირდება თანხმობა და რა ხდება უარის ან დუბლირებისას. ზოგადი ჩანაწერი „აპს ექნება შეტყობინებები“ სამუშაოს მოცულობას ვერ ადგენს.
საკუთარი notification-ის რუკა aiAPP-ის საკონტაქტო განხილვაში გააგზავნეთ, თუ უკვე იცით რა მოვლენამ უნდა გამოიწვიოს შეტყობინება.
შეტყობინების სამუშაო
შეტყობინებამ ადამიანს უნდა აცნობოს ისეთი მოვლენა, რომლის ცოდნაც აპის გარეთაც საჭიროა. ეს შეიძლება იყოს ჯავშნის დადასტურება, შეკვეთის სტატუსის ცვლილება, თანამშრომლისთვის დავალება ან უსაფრთხოების გაფრთხილება. მარკეტინგული შეთავაზება, ოპერაციული გაფრთხილება და სისტემური ტექნიკური შეტყობინება ერთ ჯგუფად არ უნდა ჩაიწეროს, რადგან მათ სხვადასხვა თანხმობა და მფლობელი სჭირდება.
დაკვეთაში თითოეულ შეტყობინებას დაურთეთ გამომწვევი მოვლენა, მიმღები, პრიორიტეტი, ტექსტი, გადასვლის ბმული და მოქმედების ვადა. მაგალითად, „შეკვეთა მზადაა“ მხოლოდ მაშინ უნდა გაიგზავნოს, როცა backend-ის სტატუსი ნამდვილად შეიცვალა. ღილაკზე დაჭერისას შეტყობინების გაგზავნამ შეიძლება დუბლირება ან ცრუ ინფორმაცია შექმნას.
Apple-ის ოფიციალური დოკუმენტაცია ამბობს, რომ alert, sound ან badge-ისთვის აპმა ავტორიზაცია უნდა მოითხოვოს. ასევე რეკომენდებულია permission-ის მოთხოვნა იმ კონტექსტში, სადაც მომხმარებელს უკვე ესმის, რატომ სჭირდება შეტყობინება. პირველი გაშვებისას უსიტყვოდ მოთხოვნილი ნებართვა ამ სამუშაოს არ ასრულებს.
თანხმობის გზა
მომხმარებელს ჯერ აუხსენით რომელი მოვლენის შესახებ მიიღებს შეტყობინებას და შემდეგ სთხოვეთ ოპერაციული სისტემის ნებართვა. თანხმობა უნდა იყოს განცალკევებული აუცილებელი მომსახურების შეტყობინებისგან და არასავალდებულო მარკეტინგისგან. მომხმარებელმა უნდა შეძლოს თემის გამორთვა აპის შიგნით, მაშინაც კი, თუ სისტემური ნებართვა ჯერ კიდევ აქტიურია.
- კონტექსტი: რომელ ქმედებამდე ან შემდეგ ჩნდება ახსნა?
- ნებართვა: რა ფუნქციისთვის ითხოვს აპი alert, sound ან badge-ს?
- არჩევანი: რომელი ტიპის შეტყობინება შეიძლება ცალკე გაითიშოს?
- გაუქმება: რა ხდება, როცა მომხმარებელი მოგვიანებით ცვლის სისტემურ უფლებას?
- დახმარება: სად ეუბნებით ადამიანს, როგორ აღადგინოს ნებართვა?
შეტყობინების permission ყველა მომხმარებელს არ უნდა მოეთხოვოს იმავე წამს. ჯავშნის აპში პრაქტიკული მომენტია პირველი ჯავშნის შექმნის შემდეგ, როცა ადამიანი უკვე ელოდება დადასტურებას. ეს მაგალითი პროდუქტის ზოგადი სცენარია და aiAPP-ის კლიენტის შემთხვევას არ აღწერს.
iOS-ისა და Android-ის განსხვავებები
iOS-ზე APNs, authorization status და notification settings აპის ცალკე კონტრაქტია. Firebase-ის Apple setup-ში საჭიროა Apple Push Notification Authentication Key და Xcode-ში Push Notifications capability. Android-ს საკუთარი permission, channel და background წესები აქვს. ამიტომ შეთავაზებაში „ერთი push ინტეგრაცია“ უნდა დაიშალოს ორივე პლატფორმის ტესტად.
INNOVATE-ის ქართული კომერციული გვერდი APNs-სა და FCM-ს push-ის შესაძლო გზებად ასახელებს. ეს ბაზრის შეთავაზების მაგალითია. aiAPP-ის პროექტში provider, არქიტექტურა, topic, token-ის შენახვა და ადმინისტრაციული მართვა ცალკე უნდა შეთანხმდეს.
რა უნდა ეწეროს შეტყობინების payload-ში?
შეტყობინების მონაცემები მხოლოდ თავისუფალი ტექსტით არ აღწეროთ. ჩაწერეთ event type, record identifier, version, deeplink, locale, expiry და ის მონაცემი, რომელიც notification-ის შიგნით მართლა უნდა გამოჩნდეს. პირადი ან ფინანსური ინფორმაცია ჩუმად არ ჩადოთ ტექსტში, რომელიც შეიძლება ჩაკეტილ ეკრანზე გამოჩნდეს.
განსაზღვრეთ განმეორებითი შეტყობინების წესი. ერთი ჯავშნისთვის შეიძლება ერთი დადასტურება, ერთი შეხსენება და ერთი ცვლილება იყოს დასაშვები. თუ backend აგზავნის ორჯერ, აპმა არ უნდა აჩვენოს მომხმარებელს ერთი და იგივე მოვლენა უსასრულოდ. ოპერატორს უნდა შეეძლოს მოძებნოს, რომელი მიზეზით გაიგზავნა კონკრეტული შეტყობინება.
რით განსხვავდება ოპერაციული, მარკეტინგული და სისტემური შეტყობინება?
| ტიპი | მაგალითი | ძირითადი კონტროლი |
|---|---|---|
| ოპერაციული | ჯავშანი დადასტურდა ან შეკვეთა შეიცვალა | ბიზნესმოვლენა და ზუსტი სტატუსი |
| მარკეტინგული | შეთავაზება ან კამპანიის შეტყობინება | დამატებითი თანხმობა და unsubscribe |
| სისტემური | ანგარიშის უსაფრთხოების გაფრთხილება | წვდომის კონტროლი და პრიორიტეტი |
თუ ყველა ტიპს ერთი არხი და ერთი ტექსტის მფლობელი ჰყავს, მომხმარებელს უჭირს შეტყობინებების მართვა, მხარდაჭერის გუნდს კი პრობლემის მიზეზის პოვნა. კატეგორიები თავიდანვე შეიტანეთ მოთხოვნების დოკუმენტში.
როგორ მიიღოთ push ინტეგრაცია?
ტესტირება გააკეთეთ ორივე პლატფორმაზე, აპის გახსნილ, ფონურ და დახურულ მდგომარეობებში. შეამოწმეთ ნებართვის მიღება, უარი, სისტემური პარამეტრის შეცვლა, არასწორი token, დუბლირებული event, deeplink, ძველი შეტყობინების ვადა და სუსტი ქსელი. შემდეგ ნახეთ, რომ სერვერის ჟურნალი და აპის ვიზუალური პასუხი ერთსა და იმავე event-ს აღწერს.
მიღების მტკიცებულება შეიძლება იყოს სატესტო მომხმარებელი, მოვლენის იდენტიფიკატორი, მიღებული payload, ეკრანის შედეგი და ჟურნალის ჩანაწერი. delivery-ის არსებობა თავისთავად არ ნიშნავს მომხმარებლის წაკითხვას ან ბიზნესის შედეგს.
რა მოამზადოთ სამუშაოს მოცულობის განხილვისთვის?
- ჩამოწერეთ თითოეული trigger და მისი ბიზნესმფლობელი.
- გამოყავით აუცილებელი, არასავალდებულო და მარკეტინგული კატეგორიები.
- აღწერეთ permission-ის ახსნა, მოთხოვნის მომენტი და უარის გზა.
- მიუთითეთ APNs/FCM ან სხვა provider-ის პასუხისმგებლობა.
- განსაზღვრეთ payload-ის მონაცემები, deeplink და დუბლირების წესი.
- დაურთეთ ორივე პლატფორმის pass/fail ტესტები.
საწყისი პაკეტი გაუგზავნეთ aiAPP-ის განხილვას. მოთხოვნების ჩეკლისტი დაგეხმარებათ notification-ის ბიზნესწესში ჩასმას, ხოლო ინტეგრაციების გვერდი მიმდინარე კავშირის კატეგორიებს აჩვენებს.
რომელი შეცდომები ქმნის ზედმეტ შეტყობინებებს?
ხშირია permission-ის მოთხოვნა აპის პირველივე ეკრანზე, ყველა მოვლენის broadcast, ერთი და იმავე შეტყობინების ორჯერ გაგზავნა და სისტემურ alert-ში პირადი მონაცემის ჩადება. ასევე ხდება provider token-ის წაშლის ან განახლების გზის გამოტოვება. ასეთი ფუნქცია შეიძლება დემოში მუშაობდეს, მაგრამ ოპერაციაში მხარდაჭერის ტვირთს ქმნის.
შეტყობინების ტექსტი უნდა აღწერდეს მოქმედებას და მომდევნო ნაბიჯს. „თქვენს ანგარიშში ცვლილებაა“ მომხმარებელს არ ეხმარება, თუ არ ჩანს რა შეიცვალა და სად უნდა გადაამოწმოს.
რა ვერ დაამტკიცებს push ფუნქცია?
push ვერ უზრუნველყოფს delivery-ს ყველა მოწყობილობაზე, მომხმარებლის წაკითხვას, გაყიდვას ან კამპანიის შედეგს. სისტემური პარამეტრები, ენერგიის დაზოგვა, ქსელი, provider-ის შეფერხება და მომხმარებლის გადაწყვეტილება გარეთ არსებული ფაქტორებია. aiAPP არ გვპირდება delivery rate-ს, engagement-ს ან კონკრეტულ არქიტექტურას.
სერვისის სამუშაოს მოცულობაში ჩაწერეთ მხოლოდ ის, რასაც თქვენი ტრიგერები, თანხმობა, პლატფორმის ტესტი და სათადარიგო გზა რეალურად ამტკიცებს.
ხშირად დასმული კითხვები
ყველა push შეტყობინებას სჭირდება მომხმარებლის თანხმობა?
ოპერაციული სისტემის წესები კონკრეტულ შეტყობინების ტიპებსა და პლატფორმაზეა დამოკიდებული. პროექტში აღწერეთ, რა უფლებას ითხოვთ, რატომ და როგორ იქცევა აპი უარის შემდეგ.
APNs და FCM ერთსა და იმავეს ნიშნავს?
ორივე შეტყობინების მიწოდების ინფრასტრუქტურასთან არის დაკავშირებული, მაგრამ iOS-სა და Android-ს განსხვავებული პლატფორმული კონტრაქტები აქვთ. შეთავაზებაში ორივე პლატფორმის ტესტი მოითხოვეთ.
შეტყობინების მიღება ბიზნესშედეგს ამტკიცებს?
არა. მიღება ამტკიცებს, რომ განსაზღვრული მოვლენა სწორ მომხმარებლამდე და სწორ გზამდე მივიდა. წაკითხვა, მოქმედება და ბიზნესშედეგი ცალკე გასაზომია.
დაკავშირებული მასალა
- მობილური აპის მოთხოვნების ჩეკლისტი
- დეველოპერის შერჩევის კრიტერიუმები
- შეტყობინებების მოცულობის განხილვა
- ინტეგრაციების გვერდი
- უსაფრთხოების ინფორმაცია
გამოყენებული წყაროები
სარედაქციო შენიშვნა: ტექსტის მომზადებაში გამოყენებულია ხელოვნური ინტელექტი.