მობილური აპის store ანგარიშის მფლობელობა და გადაცემა

აპის მაღაზიის ანგარიში ბიზნესის კონტროლქვეშ უნდა იყოს, თუ ის აპის განახლებასა და მომხმარებლის მონაცემებზეა პასუხისმგებელი. დეველოპერს საჭირო როლი მიანიჭეთ და გადაცემის საგნები წინასწარ ჩამოწერეთ.

საკუთრებისა და წვდომის საწყისი სია შეგიძლიათ aiAPP-ის საკონტაქტო განხილვაში გააგზავნოთ, რათა store-ის მოთხოვნები ტექნიკურ ფარგლებს დაემთხვეს.

ანგარიშის მფლობელობა კოდის დაწყებამდე

მობილური აპის შექმნისას ტექნიკური გუნდი მხოლოდ ეკრანებსა და ფუნქციებს არ ამზადებს. მას სჭირდება დეველოპერის ანგარიში, აპის იდენტიფიკატორი, ხელმოწერის საშუალებები, სატესტო წვდომები და მაღაზიის ჩანაწერები. თუ ეს ყველაფერი სააგენტოს პირად ანგარიშზეა მიბმული, ბიზნესს შეიძლება გაუჭირდეს განახლება, გუნდიდან ადამიანის წასვლა ან მომავალი მომწოდებლის ჩართვა.

ანგარიშის მფლობელობა ასევე ცვლის პასუხისმგებლობის საზღვარს. Apple-ის და Google Play-ის დახმარების მასალები ცალკე აღწერს გუნდის როლებს, მომხმარებლის უფლებებსა და აპის გადაცემის პირობებს. ეს დოკუმენტები გვიჩვენებს პლატფორმის მექანიზმს; ისინი არ წყვეტს იმას, ვინ უნდა იყოს თქვენი ორგანიზაციის იურიდიული და ოპერაციული მფლობელი. ეს გადაწყვეტილება ბიზნესმა უნდა ჩაიწეროს ხელშეკრულებასა და შიდა პოლიტიკაში.

მყიდველისთვის შესაფერისი მფლობელობის მოდელი

ყველაზე გამჭვირვალე მოდელში ორგანიზაცია თავად ქმნის და ფლობს App Store Connect-ისა და Google Play Console-ის ანგარიშს. დეველოპერის გუნდი ამ ანგარიშში მიწვეული მომხმარებელია კონკრეტული როლით. ასე მფლობელი აკონტროლებს პროფილს, საგადასახადო და საკონტაქტო ინფორმაციას, აპის ისტორიას და იმ ადამიანებს, რომლებიც მომავალში წვდომას მიიღებენ.

სხვა მოდელში სააგენტო ქმნის აპს საკუთარ ანგარიშში და შემდეგ ცდილობს transfer-ს. ასეთ შემთხვევაში ჯერ უნდა გადაამოწმოთ, აკმაყოფილებს თუ არა აპი Apple-ისა და Google Play-ის მოქმედ პირობებს. აპის გადაცემა შეიძლება შეეხოს იდენტიფიკატორებს, ტესტერებს, ხელმოწერას, გამოწერებს, ფინანსურ ინფორმაციას ან დაკავშირებულ სერვისებს. ამიტომ „ბოლოს გადავიტანთ“ სამუშაოს მიღების კრიტერიუმად ვერ გამოდგება.

მოდელი	ვინ აკონტროლებს ანგარიშს	რა უნდა გადაამოწმოთ
კლიენტის ანგარიში	ბიზნესი; გუნდი მოწვეული როლებით	როლების მინიმუმი, უსაფრთხო წვდომა და ორგანიზაციის საკონტაქტო მონაცემები
სააგენტოს ანგარიში	მომწოდებელი, სანამ transfer დასრულდება	გადაცემის პირობები, ვალდებულებები, ისტორია და მომავალი განახლების უფლება
შერეული მართვა	ანგარიში კლიენტს ეკუთვნის, სისტემები რამდენიმე მხარეს აქვს	რომელი რეპოზიტორი, სერვერი, გასაღები და ინტეგრაცია ვის ეკუთვნის

როლები და წვდომები

როლი უნდა აღწერდეს მოქმედებას, არა უბრალოდ ტიტულს. ანგარიშის მფლობელს შეიძლება ჰქონდეს ორგანიზაციის მართვის უფლება, ხოლო დეველოპერს მხოლოდ აპის შექმნისა და სატესტო ვერსიის ატვირთვის წვდომა. ბუღალტერს შეიძლება დასჭირდეს ფინანსური ჩანაწერი, დიზაინერს კი store-ის ვიზუალური მასალა. ერთი საერთო პაროლი ამ განსხვავებებს შლის და გადაცემას ართულებს.

• მფლობელი: ორგანიზაციის დასახელება, საკონტაქტო ელფოსტა და პასუხისმგებელი პირი.
• ტექნიკური გუნდი: კონკრეტული მომხმარებელი, როლი, ვადა და გაუქმების წესი.
• ფინანსური მხარე: გადასახადები, გაყიდვები, გამოწერა და შესაბამისი პლატფორმის მონაცემები.
• store-ის კონტენტი: აღწერა, ეკრანის სურათები, ასაკობრივი ინფორმაცია, კონფიდენციალურობა და მხარდაჭერის კონტაქტი.
• უსაფრთხოება: ორფაქტორიანი დაცვა, აღდგენის არხი და წვდომის პერიოდული გადახედვა.

როლების სია და მისი ცვლილების პროცედურა ჩაწერეთ მოთხოვნებში. საერთო მობილური აპის მოთხოვნების ჩეკლისტი ამ სიას ავსებს, მაგრამ store-ის ანგარიშის უფლებები ცალკე დანართად სჯობს დარჩეს.

რა უნდა შევიდეს გადაცემის ინვენტარში?

კოდის ფაილი მარტო აპის გადაცემას არ ნიშნავს. მიიღეთ ისეთი ინვენტარი, რომელიც სხვა სპეციალისტს პროექტის გაცნობას გაუმარტივებს. ყოველი საგნისთვის მიუთითეთ მფლობელი, მდებარეობა, წვდომის ტიპი, ბოლო შემოწმება და ცვლილების პროცედურა.

1. ანგარიშები: App Store Connect, Google Play Console, backend, დომენი, ელფოსტა, ანალიტიკა, შეტყობინებები და გარე პროვაიდერები.
2. იდენტიფიკატორები: bundle ID, package name, აპის listing, გარემოები და დაკავშირებული redirect-ები.
3. ხელმოწერა: სერტიფიკატები, გასაღებების მფლობელი, შენახვის მეთოდი და აღდგენის პროცედურა. საიდუმლო მნიშვნელობა დოკუმენტში ღია ტექსტით არ ჩაწეროთ.
4. კოდი და CI: რეპოზიტორი, branch-ების წესი, build-ის ინსტრუქცია, გარემოს ცვლადები და release pipeline.
5. ოპერაცია: backend-ის მისამართები, ლოგები, სარეზერვო ასლები, მონაცემთა წაშლის გზა და ცნობილი შეზღუდვები.
6. store მასალა: აღწერები, თარგმანები, ეკრანის სურათები, საკონფიდენციალურო ბმულები და მხარდაჭერის ტექსტი.

გადაცემის დოკუმენტს დაურთეთ წვდომის შემოწმება. მაგალითად, ბიზნესის წარმომადგენელმა უნდა ნახოს, რომ შეუძლია სატესტო ვერსიის მოძებნა, აპის ძირითადი ინფორმაციის განახლება, მხარდაჭერის არხის შეცვლა და ახალი მოწვეული მომხმარებლის გაუქმება. მოქმედება ჩაწერეთ როგორც მტკიცებულება, ხოლო პაროლი ან საიდუმლო გასაღები ცალკე უსაფრთხო არხით გადაიტანეთ.

როგორ დაასრულოთ გადაცემა მიღების პირობებით?

გადაცემის მიღება არ უნდა შემოიფარგლოს ხელმოწერით, რომ ფაილები „გადმოიგზავნა“. განსაზღვრეთ, რომელი შედეგი აჩვენებს რეალურ კონტროლს. მფლობელმა უნდა შეძლოს ანგარიშში შესვლა, წვდომების ნახვა, განახლების პროცესის დაწყება და მხარდაჭერის ინფორმაციის პოვნა. ტექნიკურმა წარმომადგენელმა უნდა შეძლოს კოდის აწყობა და სატესტო გარემოს ამოქმედება იმ ინსტრუქციით, რომელიც მიღებას ახლავს.

Apple-ის აპის transfer დოკუმენტში აღწერილი პირობები და Google Play-ის transfer დახმარება პერიოდულად შეიძლება შეიცვალოს. ამიტომ კონტრაქტში ჩაწერეთ პასუხისმგებლობა მოქმედი წესის გადამოწმებაზე კონკრეტული გადაცემის დროს. წყაროს გვერდი ამტკიცებს პლატფორმის მიმდინარე პროცესს, მაგრამ ვერ ამტკიცებს თქვენი აპის eligibility-ს ან მაღაზიის საბოლოო გადაწყვეტილებას.

შეგიძლიათ შეფასებისთვის გამოიყენოთ დეველოპერის შერჩევის კრიტერიუმები და ცალკე მოითხოვოთ მტკიცებულება, რომ მომწოდებელმა გადაცემის ყველა მხარე გაითვალისწინა.

რა ნაბიჯებით მოამზადოთ ანგარიში და გადაცემა?

1. დაასახელეთ იურიდიული და ოპერაციული მფლობელი ორივე პლატფორმაზე.
2. შექმენით ორგანიზაციის ანგარიშები და აღდგენის არხები თქვენს კონტროლში.
3. დაწერეთ როლების მატრიცა: ვინ ქმნის, ტესტავს, აქვეყნებს და აუქმებს წვდომას.
4. გაყავით store-ის შინაარსი, აპის კოდი, backend და გარე ინტეგრაციები ცალკე აქტივებად.
5. შეთანხმდით, სად ინახება სერტიფიკატები და როგორ ხდება საიდუმლოს ჩანაცვლება.
6. მიღებისას შეასრულეთ კონტროლის სცენარები და შეინახეთ ეკრანის ან audit-ის მტკიცებულება.
7. დახურეთ მომწოდებლის დროებითი მომხმარებლები ან შეამცირეთ მათი როლი ხელშეკრულების მიხედვით.

ამ გეგმის დასაწყებად გამოიყენეთ aiAPP-ის პროექტის განხილვა. კომერციული ფორმატი გადაამოწმეთ მოქმედ გვერდზე, ხოლო ანგარიშებისა და საიდუმლოებების დაცვის საკითხები შეადარეთ უსაფრთხოების აღწერას.

რომელი შეცდომები ართულებს მფლობელობის გადაცემას?

პირველი შეცდომაა აპის გამოქვეყნება გუნდის პირად ანგარიშზე იმ იმედით, რომ მომავალში ყველაფერი გადავა. მეორეა საერთო პაროლი, რომელსაც რამდენიმე ადამიანი ცვლის. მესამეა მხოლოდ store-ის listing-ის გადაცემა, მაშინ როცა backend, analytics ან push სერვისი სხვა ანგარიშზე რჩება. მეოთხეა სერტიფიკატის არსებობის აღრევა მის უსაფრთხო მფლობელობასთან.

ასევე არასწორია ხელშეკრულებაში მხოლოდ „კოდის ჩაბარების“ ჩაწერა. თუ არ ჩანს build-ის ინსტრუქცია, გარემოს ცვლადები, წვდომების მფლობელი და განახლების პროცესი, ბიზნესს შეიძლება ჰქონდეს ფაილები, მაგრამ არა მართვადი პროდუქტი. ეს საკითხები ცალკე სცენარებად ჩამოწერეთ.

რას ვერ დაგპირდებათ ანგარიშის სწორი მფლობელობა?

კლიენტის ანგარიშზე აპის ქონა მაღაზიის მიღებას, გამორჩეულ პოზიციას, გაყიდვას ან მომხმარებელთა რაოდენობას არ ამტკიცებს. გადაცემა ვერ ცვლის Apple-ისა და Google Play-ის წესებს, საგადასახადო ვალდებულებებს ან მესამე მხარის კონტრაქტს. store-ის მოთხოვნა შეიძლება შეიცვალოს, ხოლო გარე კავშირი ცალკე შეფერხდეს.

სწორი მფლობელობა მხოლოდ კონტროლის წინაპირობას ქმნის. საბოლოო შედეგი დამოკიდებულია თქვენს მოთხოვნებზე, აპის ტექნიკურ მდგომარეობაზე, კონფიდენციალურობის დოკუმენტებზე, ტესტირებასა და იმ პლატფორმის გადაწყვეტილებაზე, რომელზეც აპის ჩანაწერი იგზავნება.

ხშირად დასმული კითხვები

აუცილებელია თუ არა store ანგარიში ბიზნესის სახელზე?

მფლობელი უნდა იყოს ის ორგანიზაცია ან პირი, ვინც აპის კონტროლსა და მომავალ ოპერაციებზე რეალურად არის პასუხისმგებელი. კონკრეტული ანგარიშის ტიპი და უფლებები პლატფორმის მოქმედ წესებთან ერთად გადაამოწმეთ.

შეიძლება თუ არა დეველოპერს ადმინისტრატორის უფლება ჰქონდეს?

შეიძლება, თუ კონკრეტული სამუშაო ამას მოითხოვს და წვდომა ინდივიდუალურ მომხმარებელზე, ვადასა და გაუქმების წესზეა მიბმული. საერთო პაროლი და მუდმივი გაუმართლებელი ადმინისტრატორის წვდომა კონტროლს ამცირებს.

საკმარისია თუ არა აპის ფაილების გადმოცემა?

არა. მიღების პაკეტში უნდა ჩანდეს ანგარიშები, build-ის გზა, backend, გარე სერვისები, store-ის მასალა, საიდუმლოებების მართვა, დოკუმენტაცია და ცნობილი შეზღუდვები.

დაკავშირებული მასალა

• მობილური აპის მოთხოვნების ჩეკლისტი ბიზნესისთვის
• როგორ შევარჩიოთ მობილური აპის დეველოპერი
• aiAPP-ის პროექტის განხილვა
• aiAPP-ის სამუშაო ფორმატი
• უსაფრთხოების მიმდინარე აღწერა

გამოყენებული წყაროები

• developer.apple.com
• developer.apple.com
• support.google.com
• support.google.com

სარედაქციო შენიშვნა: ტექსტის მომზადებაში გამოყენებულია ხელოვნური ინტელექტი.