მობილური აპის ანალიტიკა: რა უნდა ჩაიწეროს დაკვეთაში
მობილური აპის ანალიტიკის დაკვეთის პრაქტიკული ჩარჩო: მოვლენები, თანხმობა, მონაცემის ხარისხი და მიღების კრიტერიუმები.
მობილური აპის ანალიტიკა უნდა აღწერდეს მომხმარებლის მნიშვნელოვან მოქმედებებს და არა მხოლოდ ჩამოტვირთვების რიცხვს. შეკვეთაში წინასწარ ჩაიწეროს, რომელ კითხვას პასუხობს თითოეული მოვლენა, რა მონაცემი სჭირდება მას, ვინ ხედავს ანგარიშს და როგორ მოწმდება, რომ მოვლენა სწორ დროს ერთხელ ჩაიწერა.
ანალიტიკის შესყიდვის საზღვარი
მომწოდებლის შეთავაზებაში „ანალიტიკა“ შეიძლება ნიშნავდეს მაღაზიის ჩამოტვირთვების ანგარიშს, აპში ჩაშენებულ მოვლენებს, შეცდომების მონიტორინგს ან მარკეტინგული კამპანიის გაზომვას. ეს სხვადასხვა სამუშაოა. შეკვეთამდე ჩამოწერეთ კონკრეტული გადაწყვეტილებები: უნდა გაიგოთ, სად წყდება რეგისტრაცია, რომელი ნაბიჯიდან ბრუნდება მომხმარებელი თუ რომელ მოქმედებამდე ვერ აღწევს. მხოლოდ ამის შემდეგ გადაწყდება, რომელი მონაცემის შეგროვებაა საჭირო.
თუ დაკვეთის ფინანსურ ჩარჩოსაც ადგენთ, გადახედეთ aiAPP-ის მომსახურების პირობებს და ანალიტიკის მოცულობა ცალკე მიუთითეთ. საწყისი მოთხოვნების ჩამოსაწერად გამოგადგებათ ბიზნესის მოთხოვნების ჩეკლისტი; მომწოდებლის პასუხისმგებლობის გასამიჯნად იხილეთ დეველოპერის არჩევის კრიტერიუმები.
მაგალითად, ჯავშნის აპში „ჯავშანი დაიწყო“ და „ჯავშანი დადასტურდა“ სხვადასხვა მოვლენაა. პირველი შეიძლება მოხდეს მანამდე, სანამ მომხმარებელი აირჩევს დროს; მეორე მხოლოდ მაშინ, როცა სისტემამ საბოლოო პასუხი დააბრუნა. თუ ორივე ერთ სახელში ჩაიწერა, ანგარიში შეცდომაში შეიყვანს მენეჯერს. ეს მაგალითი პირობითია და aiAPP-ის არსებულ კლიენტს არ აღწერს.
მოვლენების რუკა
თითოეულ მოვლენას დაურთეთ სახელი, ბიზნესკითხვა, გაშვების პირობა, დასაშვები პარამეტრები და ტესტის სცენარი. ჯავშნის დადასტურებისას განსაზღვრეთ, ჩაიწერება მოვლენა ღილაკზე დაჭერისას თუ მხოლოდ სერვერის პასუხის შემდეგ. ცალკე მიუთითეთ, როგორ მოიქცევა აპი კავშირის დაკარგვის, განმეორებითი დაჭერისა და შეცდომის შემთხვევაში. იგივე სახელები და პირობები უნდა მუშაობდეს iOS-სა და Android-ზე, თუ ორივე პლატფორმა შეთანხმებულ მოცულობაშია.
საწყის რუკაში შეიტანეთ მხოლოდ ის მოქმედებები, რომლებზეც გუნდი რეალურად მიიღებს გადაწყვეტილებას. ეკრანის ყველა შეხების აღრიცხვა ძვირადღირებულ ხმაურს ქმნის და მონაცემთა დაცვის კითხვებს ამატებს. აპის მფლობელს შეუძლია მომწოდებელს სთხოვოს ცხრილი, სადაც თითოეული მოვლენა უკავშირდება ეკრანს, მონაცემის წყაროს, შემოწმების მეთოდს და ანგარიშში გამოსაყენებელ განმარტებას.
- თითოეულ მოვლენას დაურთეთ ბიზნესკითხვა და გაშვების ზუსტი პირობა.
- განსაზღვრეთ, რომელი პარამეტრი ნამდვილად საჭიროა და ვის აქვს მისი ნახვის უფლება.
- iOS-სა და Android-ზე ერთი და იგივე მოქმედება ერთნაირი მნიშვნელობით შეამოწმეთ.
- მიღებისას სატესტო გზით გადაამოწმეთ, რომ მოვლენა სწორ მომენტში და განმეორების გარეშე ჩაიწერა.
როგორ განსხვავდება მაღაზიის ანგარიში და აპის მოვლენები?
App Store Connect-ის ანალიტიკა აჩვენებს მაღაზიისა და აპის გამოყენების გარკვეულ მაჩვენებლებს, თუმცა Apple განმარტავს, რომ გამოყენების მონაცემები დამოკიდებულია მომხმარებლის გაზიარების არჩევანსა და კონფიდენციალურობის ზღვრებზე. ამიტომ მაღაზიის ანგარიში ვერ ჩაანაცვლებს თქვენს აპში ზუსტად განსაზღვრული ბიზნესმოვლენების შემოწმებას. თავის მხრივ, აპში მოვლენების დამატება არ ნიშნავს, რომ მაღაზიის ჩამოტვირთვების რიცხვი იმავე განმარტებით ჩაიწერება. ორი წყარო ცალკე აღწერეთ და მათი მაჩვენებლები დაუფიქრებლად არ შეკრიბოთ.
რომელი მონაცემის საზღვარი უნდა განისაზღვროს?
ანალიტიკის შეკვეთას უნდა ახლდეს მონაცემთა სია: რა იწერება, ვის შეიძლება მიეწოდოს და რამდენ ხანს ინახება. მომხმარებლის სახელი, ტელეფონი ან ზუსტი მდებარეობა ბიზნესმოვლენის ასათვლელად ავტომატურად საჭირო არ არის. Apple-ის კონფიდენციალურობის მოთხოვნები ცალკე ითვალისწინებს მესამე მხარის ანალიტიკურ კოდსაც: აპის მფლობელმა უნდა იცოდეს, რას აგროვებს დამატებული ბიბლიოთეკა. ეს იურიდიული დასკვნა არ არის; კონკრეტული მონაცემის დამუშავების საფუძველი და შეტყობინება ცალკე უნდა შემოწმდეს.
როგორ მიიღოს ბიზნესმა შესრულებული სამუშაო?
მიღებისას გუნდმა სატესტო ტელეფონებზე გაიაროს წინასწარ დაწერილი გზები და შეადაროს აპის ფაქტობრივი მოქმედება მოვლენების ჟურნალს. შეამოწმეთ წარმატება, უარი, კავშირის დაკარგვა და განმეორებითი მოქმედება. სთხოვეთ მომწოდებელს აჩვენოს, რომ სატესტო მონაცემი არ ერევა რეალურ ანგარიშში და რომ ბიზნესმომხმარებელი ხედავს ანგარიშის განმარტებებს. თუ რომელიმე მოვლენა სწორად ჩაიწერა მხოლოდ ერთ პლატფორმაზე, ორივე პლატფორმის სამუშაო დასრულებულად არ ჩაითვლება.
ცალკე შეთანხმდით, ვის ექნება ანგარიშის ადმინისტრატორის წვდომა და როგორ გადაეცემა იგი აპის მფლობელს. კონტრაქტში სასარგებლოა ჩაიწეროს, ვის ეკუთვნის მოვლენების სახელების სია, ვინ ადასტურებს მის ცვლილებას და როგორ ინიშნება ახალი ვერსიის ამოქმედების თარიღი. თუ „ჯავშნის დასრულების“ განმარტება მოგვიანებით შეიცვლება, ძველ და ახალ პერიოდს ერთსა და იმავე მაჩვენებლად ვეღარ შეადარებთ. ანგარიშის მფლობელმა უნდა შეძლოს ცვლილების მიზეზის პოვნა ისე, რომ დეველოპერს ყოველ ჯერზე არ დაუკავშირდეს.
მომწოდებლის შეფასებისას სთხოვეთ პატარა საჩვენებელი მიღების სცენარი: სატესტო მომხმარებელი იწყებს მოქმედებას, ტოვებს ფორმას, ბრუნდება და საბოლოოდ ასრულებს მას. წინასწარ შეთანხმებულ ჟურნალში უნდა ჩანდეს სწორედ ის მოვლენები, რომლებიც ამ გზისთვის განსაზღვრეთ. თუ ანგარიში მხოლოდ საბოლოო ჯამს აჩვენებს და ცალკეული ნაბიჯების შემოწმება ვერ ხერხდება, მიღებისას მიზეზის დადგენაც გაჭირდება. ასეთი შემოწმება სამუშაოს მოცულობის ნაწილია, არა წარმატებული ბიზნესშედეგის გარანტია.
aiAPP-ის დადასტურებული მომსახურება მოიცავს ახალი iOS და Android აპის დაგეგმვას, პროტოტიპს, განვითარებას, ტესტირებასა და გადაცემას. ანალიტიკის კონკრეტული ხელსაწყო, მოვლენების რაოდენობა და ანგარიშის ფორმა შეთანხმებულ პროექტში უნდა განისაზღვროს; ეს სტატია მათ ჩაშენებულ შესაძლებლობად არ აცხადებს. თუ აპის დაკვეთას ამზადებთ, გაუგზავნეთ aiAPP-ს თქვენი ძირითადი მომხმარებლის გზა და გაზომვის კითხვები, რათა ანალიტიკის მოცულობა წერილობით განისაზღვროს.
რა ვერ დაამტკიცებს ანალიტიკა?
მოვლენების სწორი ჩაწერა თავისთავად არ ამტკიცებს გაყიდვების ზრდას, მომხმარებლის კმაყოფილებას ან კამპანიის მიზეზობრივ შედეგს. მცირე მოცულობის ანგარიშში პირადი მონაცემის დაცვის გამო ზოგი მაჩვენებელი შეიძლება საერთოდ არ გამოჩნდეს. მონაცემის ინტერპრეტაციას სჭირდება ერთნაირი განმარტებები, პერიოდი და ცვლილებების ისტორია. თუ პროდუქტის გუნდმა ჯერ არ იცის, რა გადაწყვეტილებას მიიღებს ანგარიშის მიხედვით, პირველ რიგში სწორედ ეს კითხვა უნდა დააზუსტოს.
საბოლოო მოთხოვნაში ცალკე დატოვეთ კითხვა, ვის ევალება ყოველდღიური მონიტორინგი. აპის შექმნა და მისი შემდგომი ანალიზის მართვა ერთსა და იმავე მომსახურებად ავტომატურად არ უნდა ჩაითვალოს. შეთანხმების გარეშე მონაცემები შეიძლება შეგროვდეს, მაგრამ არც ერთმა პასუხისმგებელმა პირმა არ გამოიყენოს.
წყაროები
Firebase-ის მოვლენების სახელმძღვანელო: მოვლენები აღწერს აპში მოქმედებებს; კონკრეტული ხელსაწყო aiAPP-ის ჩაშენებულ ფუნქციად არ არის გამოცხადებული.
სარედაქციო შენიშვნა: ტექსტის მომზადებაში გამოყენებულია ხელოვნური ინტელექტი.