Air app release что это

Команда ADT package

Команда -package всегда должна запускаться из основного каталога приложения. Команда имеет следующий синтаксис:

Создание пакета AIR на основе файлов компонентов приложения:

adt -package AIR_SIGNING_OPTIONS -target packageType -sampler ‑hideAneLibSymbols NATIVE_SIGNING_OPTIONS output app_descriptor FILE_OPTIONS

Создание собственного пакета платформы на основе файлов компонентов приложения:

adt -package AIR_SIGNING_OPTIONS -target packageType DEBUGGER_CONNECTION_OPTIONS -airDownloadURL URL NATIVE_SIGNING_OPTIONS output app_descriptor -platformsdk path FILE_OPTIONS

Создание собственного пакета платформы, включающего собственное расширение, на основе файлов компонентов приложения:

adt -package AIR_SIGNING_OPTIONS -migrate MIGRATION_SIGNING_OPTIONS -target packageType DEBUGGER_CONNECTION_OPTIONS -airDownloadURL URL NATIVE_SIGNING_OPTIONS output app_descriptor -platformsdk path FILE_OPTIONS

Создание исходного пакета на основе файла AIR или AIRI:

adt -package -target packageType NATIVE_SIGNING_OPTIONS output input_package

Создайте пакет собственного расширения из файлов собственного расширения компонента:

adt -package AIR_SIGNING_OPTIONS -target ane output ANE_OPTIONS

Примечание. ANE-файл можно не назначать, поэтому параметры AIR_SIGNING_OPTIONS являются необязательными в этом примере.

AIR_SIGNING_OPTIONS Параметры подписи AIR задают сертификат, который используется для подписания файла установки AIR. Параметры подписи описаны в разделе « Параметры подписания кода ADT ».

-migrate . Этот флаг указывает, что приложение подписано сертификатом переноса в дополнение к сертификату, указанному в параметрах AIR_SIGNING_OPTIONS . Этот флаг допустим, только если упаковывается приложение для настольных компьютеров в качестве собственного установщика и в приложении используется собственное расширение. В других случаях возникнет ошибка. Параметры подписи для сертификата переноса указываются в параметрах MIGRATION_SIGNING_OPTIONS . Эти параметры подписи описаны в разделе « Параметры подписания кода ADT ». Флаг -migrate позволяет создавать обновления для приложений с собственным файлом установки настольной платформы, использующих собственное расширение платформы, а также изменять сертификат подписи кода приложения в тех случаях, например, когда срок оригинального сертификата истек. Дополнительные сведения см. в разделе « Подписание обновленной версии приложения AIR ».

Флаг -migrate команды -package доступен в версиях AIR 3.6 и более поздних.

• air — пакет AIR. «air» — это значение по умолчанию. При создании файлов AIR и AIRI указывать флаг -target не требуется.
• airn — исходный пакет приложения для устройств с расширенным профилем телевизионных устройств.
• ane — пакет собственных расширений AIR
• Целевые объекты пакета Android:
  • apk — пакет Android. Пакет такого типа может быть установлен только на устройство Android, не на эмулятор.
  • apk‑captive‑runtime — пакет Android, включающий приложение и встроенную версию среды выполнения AIR. Пакет такого типа может быть установлен только на устройство Android, не на эмулятор.
  • apk-debug — пакет Android с дополнительной информацией для отладки. (SWF-файлы приложения также должны быть скомпилированы с поддержкой отладки.)
  • apk-emulator — пакет Android, предназначенный для использования в эмуляторе без поддержки отладки. (Чтобы разрешить отладку одновременно на эмуляторе и устройстве, используйте флаг apk-debug.)
  • apk-profile — пакет Android, поддерживающий профили производительности и памяти приложения.
  • ipa-ad-hoc — пакет iOS для специального развертывания.
  • ipa-app-store — пакет iOS для распространения через Apple App Store.
  • ipa-debug — пакет an iOS с дополнительной информацией для отладки. (SWF-файлы приложения также должны быть скомпилированы с поддержкой отладки.)
  • ipa-test — пакет iOS, скомпилированный без информации для оптимизации и отладки.
  • ipa-debug-interpreter — функциональные возможности, как у пакета отладки, но компиляция выполняется быстрее. Однако байт-код ActionScript интерпретируется и не преобразуется в машинный код. Поэтому в пакете интерпретатора код выполняется медленнее.
  • ipa-debug-interpreter-simulator — функциональность эквивалентна ipa-debug-interpreter, но пакет предназначен для приложения iOS Simulator. Только для компьютеров Macintosh. Если используется этот параметр, необходимо также добавить параметр -platformsdk, указав путь к набору средств SDK приложения iOS Simulator.
  • ipa-test-interpreter — функциональные возможности, как у пакета тестирования, но компиляция выполняется быстрее. Однако байт-код ActionScript интерпретируется и не преобразуется в машинный код. Поэтому в пакете интерпретатора код выполняется медленнее.
  • ipa-test-interpreter-simulator — функциональность эквивалентна ipa-test-interpreter, но пакет предназначен для приложения iOS Simulator. Только для компьютеров Macintosh. Если используется этот параметр, необходимо также добавить параметр -platformsdk, указав путь к набору средств SDK приложения iOS Simulator.
  • EXE — Windows
  • DMG — Mac
  • DEB — Ubuntu Linux (AIR 2.6 или более ранней версии)
  • RPM — Fedora или OpenSuse Linux (AIR 2.6 или более ранней версии)

  -sampler (только iOS, AIR 3.4 и более поздней версии) Включает сэмплер ActionScript, основанный на телеметрии, в приложениях для iOS. Использование этого флага позволяет произвести профилирование приложения с помощью инструмента Adobe Scout. Несмотря на то, что инструмент Scout позволяет выполнить профилирование любого содержимого платформы Flash, включение подробной телеметрии дает более полное представление о времени вызова функций ActionScript, списке DisplayList, визуализации Stage3D и т. д. Включение этого флага приводит к незначительному ухудшению производительности, поэтому не используйте его в окончательных сборках приложений.

  -hideAneLibSymbols (только iOS, AIR 3.4 и более поздних версий) Разработчики приложений могут использовать несколько расширений в машинном коде из различных источников, и если файлы ANE содержат одинаковые имена символов, ADT сгенерирует ошибку «duplicate symbol in object file» (дублирование символов в объектном файле). В некоторых случаях эта ошибка может проявиться в виде непредвиденного завершения во время выполнения. Параметр hideAneLibSymbols позволяет указать, сделать ли символы библиотеки ANE видимыми только для исходных кодов только этой библиотеки (yes) или видимыми глобально (no):

  • yes — скрывает символы ANE, за счет чего устраняются любые непреднамеренные конфликты имен.
  • no — (по умолчанию) символы ANE не скрываются. Это поведение соответствует версиям AIR ниже 3.4

  -embedBitcode (только для ОС iOS, AIR 25 или более поздних версий) Разработчики могут использовать параметр embedBitcode для указания того, требуется ли встраивать двоичный код в приложения для iOS («Да» или «Нет»). Если не указано иное, для этого параметра используется значение по умолчанию «Нет».

  DEBUGGER_CONNECTION_OPTIONS Параметры подключения к отладчику указывают, должен ли пакет отладки подключаться к удаленному отладчику, запущенному на другом компьютере, или прослушивать соединение удаленного отладчика. Этот набор параметров поддерживают только мобильные пакеты отладки (с типом apk-debug и ipa-debug). Эти параметры описаны в разделе « Параметры подключения к отладчику ».

  -airDownloadURL — указывает альтернативный URL для загрузки и установки среды выполнения AIR на устройствах Android. Если параметр не указан и среда выполнения не установлена, приложение AIR будет перенаправлять пользователя к среде выполнения AIR на Android Маркет.

  Если приложение распространяется через альтернативные рынки (отличные от Android Маркета, управляемого Google), возможно потребуется указать URL для загрузки среды выполнения AIR с этого рынка. Некоторые альтернативные рынки не разрешают приложениям запрашивать загрузку из внешних источников. Этот параметр поддерживается только пакетами Android.

  NATIVE_SIGNING_OPTIONS Параметры исходной подписи указывают сертификат, который используется для подписания файла исходного пакета. Данный параметр предназначен для применения подписи, используемой исходной операционной системой, не средой выполнения AIR. В остальном параметры идентичны параметрам AIR_SIGNING_OPTIONS. Подробное описание этих параметров приведено в разделе Параметры подписания кода ADT .

  Исходные подписи поддерживаются в Windows и Android. В Windows необходимо задать параметры подписи AIR и параметры исходной подписи. В Android можно задать только параметры исходной подписи.

  Во многих случаях для применения подписи AIR и исходной подписи можно использовать сертификат подписи кода. Однако это верно не для всех ситуаций. Например, в соответствии с политикой Google для приложений, размещаемых в Android Маркете, необходимо, чтобы все приложения были подписаны сертификатом, действительным по крайней мере до 2033 года. Это означает, что для подписания приложений Android не следует использовать сертификат, выданный известным сертифицирующим органом, который рекомендуется для применения подписи AIR (ни один из сертифицирующих органов не выдает сертификаты для подписания кода с таким сроком действия).

  output — имя создаваемого файла пакета. Указание расширения файла не является обязательным. Если расширение не указано, добавляется расширение, определяемое значением параметра -target и текущей операционной системой.

  app_descriptor — путь к файлу дескриптора приложения. Можно задать абсолютный путь или путь относительно текущей директории. (В файле AIR имя файла дескриптора приложения изменяется на application.xml .)

  • Android — в состав пакета SDK AIR 2.6 и более поздних версий включены инструменты из пакета SDK для ОС Android, необходимые для реализации соответствующих команд ADT. Данный параметр следует задавать только для использования другой версии Android SDK. Кроме того, путь к платформе SDK не требуется указывать в командной строке, если уже установлена переменная среды AIR_ANDROID_SDK_HOME (если заданы оба значения, используется путь, указанный в командной строке).
  • iOS — в комплект поставки набора средств SDK для AIR входит связанный набор SDK для iOS. Параметр -platformsdk позволяет создавать пакеты приложений с внешним набором средств SDK, чтобы не ограничиваться использованием только набора SDK для iOS. Например, если с помощью самой последней версии набора SDK для iOS создано расширение, можно указать этот набор SDK при формировании пакета приложения. Кроме того, если вместе с приложением iOS Simulator используется ADT, необходимо всегда добавлять параметр -platformsdk, указав путь к набору средств SDK приложения iOS Simulator.

  -arch Разработчики приложений могут использовать этот аргумент, чтобы создавать APK для платформ x86, принимает следующие значения:

  • armv7 — ADT упаковывает APK для платформы Android armv7.
  • x86 — ADT упаковывает APK для платформы Android x86.

  armv7 используется по умолчанию, если значение не определено

  FILE_OPTIONS — указывает, какие файлы приложения включаются в пакет. Подробное описание параметров файлов приведено в разделе « Параметры файлов и путей ». Не указывайте параметры файлов при создании исходного пакета на основе файла AIR или AIRI.

  input_airi — указывается при создании исходного пакета из файла AIRI. Параметр AIR_SIGNING_OPTIONS требуется указать, если для пакета задан тип air (или тип пакета не указан).

  input_air Указывается при создании исходного пакета на основе файла AIR. Не указывайте параметр AIR_SIGNING_OPTIONS.

  ANE_OPTIONS — указываются параметры и файлы для создания пакета собственных расширений. Полное описание параметров пакета расширений приводится в разделе Параметры собственных расширений .

  Примеры использования команды ADT -package

  Упаковка файлов приложения в текущей папке для приложения AIR на основе SWF:

  adt –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml myApp.swf components.swc

  Упаковка файлов приложения в текущей папке для приложения AIR на основе HTML:

  adt –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml myApp.html AIRAliases.js image.gif

  Упакуйте все файлы и подкаталоги в текущем рабочем каталоге:

  adt –package -storetype pkcs12 -keystore ../cert.p12 myApp.air myApp.xml .

  Примечание. Файл-хранилище ключей содержит закрытый ключ, которым подписано приложение. Ни в коем случае не упаковывайте сертификат подписи в пакет AIR! Если в командах ADT используются знаки подстановки, поместите файл-хранилище ключей в другую папку, чтобы он не попал в пакет. В этом примере файл-хранилище ключей cert.p12 находится в родительском каталоге.

  Включайте в пакет только основные файлы и подкаталог images:

  adt –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml myApp.swf images

  Включайте в пакет HTML-приложение и все файлы в подкаталогах HTML, scripts и images:

  adt –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml index.html AIRALiases.js html scripts images

  Включайте в пакет файл application.xml и основной SWF-файл в рабочем каталоге (release/bin):

  adt –package -storetype pkcs12 -keystore cert.p12 myApp.air release/bin/myApp.xml –C release/bin myApp.swf

  Включайте в пакет ресурсы более чем из одного места в файловой системе сборки. В этом примере ресурсы приложения до упаковки находятся в следующих папках:

  /devRoot /myApp /release /bin myApp-app.xml myApp.swf or myApp.html /artwork /myApp /images image-1.png . image-n.png /libraries /release /libs lib-1.swf lib-2.swf lib-a.js AIRAliases.js

  Выполнение команды ADT из каталога /devRoot/myApp:

  adt –package -storetype pkcs12 -keystore cert.p12 myApp.air release/bin/myApp-app.xml –C release/bin myApp.swf (or myApp.html) –C ../artwork/myApp images –C ../libraries/release libs

  создает следующую структуру пакета:

  /myAppRoot /META-INF /AIR application.xml hash myApp.swf or myApp.html mimetype /images image-1.png . image-n.png /libs lib-1.swf lib-2.swf lib-a.js AIRAliases.js

  Запустите ADT в качестве программы Java для простого приложения на основе SWF (без указания пути к классам):

  java –jar /lib/ADT.jar –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml myApp.swf

  Запустите ADT в качестве программы Java для простого приложения на основе HTML (без указания пути к классам):

  java –jar /lib/ADT.jar –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml myApp.html AIRAliases.js

  Запустите ADT как программу Java (путь к классу Java должен включать пакет ADT.jar):

  java -com.adobe.air.ADT –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml myApp.swf

  Запускает ADT в виде задачи Java в Apache Ant (несмотря на то, что рекомендуемым вариантом является запуск команды ADT непосредственно из скрипта Ant). Пути в данном примере указаны для ОС Windows:

   /lib/adt.jar"/> target name="package">           

  Примечание. В некоторых системах двухбайтные символы, входящие в путь файла, могут быть интерпретированы неверно. Если это произойдет, попробуйте настроить для среды JRE, с помощью которой запускается ADT, использование набора символов UTF-8. Это выполняется по умолчанию в сценарии, который используется для запуска ADT на Mac и Linux. В фале adt.bat для Windows или при запуске ADT непосредственно из Java укажите параметр ‑Dfile.encoding=UTF-8 в командной строке Java.

  

  

  На посты, размещаемые в Twitter™ и Facebook, условия Creative Commons не распространяются.

  Как российское приложение для авиагиков попало в акселератор от Google

  Сооснователь сервиса для путешественников App in the Air Байрам Аннаков — об истории проекта и проблемах, которые мешали его запуску.

  Байрам Аннаков

  Приложение App in the Air — персональный ассистент полетов, который предоставляет пользователю информацию о состоянии рейса, собирает статистику путешествий и помогает ориентироваться в аэропортах.

  С помощью сервиса пользователь может зарегистрироваться на рейс, получить информацию об изменении в расписании или настроить автоматическую отправку SMS-сообщения близким о прилете.

  В 2018 году App in the Air попал в бесплатную программу акселератора Google Launchpad, которая включает в себя обучение в Сан-Франциско, а также консультации с экспертами Google, специалистами ИТ-компаний и зарубежных венчурных фондов.

  Сооснователь и руководитель проекта App in the Air Байрам Аннаков рассказал vc.ru о том, как получается договариваться с авиакомпаниями, почему целевая аудитория сервиса — это авиагики, и что тормозило запуск приложения.

  Чат для знакомств

  В 2011 году Аннаков преподавал в МГУ и предоставлял консалтинговые услуги вместе со своими студентами. Также у команды была своя компания Empatika, которая занималась разработкой приложений.

  Доходы от консалтинга позволили создать и запустить сервис Squeek, с помощью которого пользователи могли общаться и знакомиться с теми, кто находится поблизости. «Что еще могли придумать пять гиков-айтишников, чтобы знакомиться с девушками, не подходя к ним», — иронизирует Аннаков.

  Примером для подражания Empatika служила команда Instagram — 13 человек смогли создать и запустить продукт, у которого теперь более 50 млн пользователей, рассказывает основатель компании.

  Приложение Squeek, рассчитанное на публичные места, пользовалось спросом у студентов МГУ и ГУ ВШЭ, а также у пассажиров в аэропортах. Команда проекта поняла, что не хочет развивать сервис в университетах, так как студенческую нишу легко мог покрыть «ВКонтакте», и решила сконцентрироваться на аэропортах.

  К 2012 году команда проекта перестала развивать чат и взялась за разработку сервиса для авиапассажиров.

  Разработка App in the Air

  Аннаков и еще четверо сотрудников занялись разработкой ассистента для пользователей, которые совершают в среднем 30 полетов в год. Проект получил название App in the Air, которое стало отсылкой к фильму «Мне бы в небо» (Up in the Air) с Джорджем Клуни в главной роли.

  Проект решил привлечь средства от стороннего инвестора. Им в мае 2012 года стал фонд IMI.

  Аннаков не раскрывает долю инвестора, а также сумму, потраченную на запуск App in the Air, но говорит, что за всё время сотрудничества фонд вложил около $2 млн.

  Еще одним отличием от Squeek стал ключевой рынок — разработчики решили продвигать продукт для пассажиров на Западе. Первыми странами стали США и Великобритания.

  Аннаков поясняет, что такое решение связано с распространённостью смартфонов и высокой частотой перелётов граждан этих стран. В России проникновение мобильных устройств и количество полетов на 1000 жителей в разы меньше, чем в США, Великобритании, Германии, Индии и Китае, добавляет сооснователь App in the Air.

  Сейчас 34% пользователей сервиса проживают в США, 25% аудитории находятся в странах Евросоюза, 12% — в Великобритании, 10% — в России. Оставшиеся 19% — это жители Индии, Бразилии, Индонезии и других стран. Компания не ведет активных действий в Китае, который, по мнению Аннакова, представляет собой сложный специфический рынок.

  Кроме того, изначально App in the Air выпускалось только под iOS, так как среди часто летающих клиентов в Европе доля устройств Apple выше, чем под управлением Android. В дальнейшем стартап выяснил, что более 60% азиатских пользователей, совершающих частые перелеты, владеют Android-смартфонами.

  На разработку ушло девять месяцев. Аннаков считает, что это слишком большой срок — можно было уложиться в четыре месяца и оперативнее выпустить продукт, чтобы собрать обратную связь от пользователей.

  Страх — это единственное, что оттягивало запуск продукта. Есть глубинная проблема — страх облажаться — и есть то, как команда его закрывает. Например, пытается впихнуть в приложение все функции, которые можно придумать, до невозможности полирует качество и находит новые ошибки.

  Мы проводили интервью с потенциальными пользователями и бета-тестирование, но все методологии — это попытка скрыть страх, что ты выпустишь продукт, который провалится.

  Байрам Аннаков
  Кризис после релиза

  По мнению Аннакова, реальная жизнь стартапа начинается с выпуска продукта и сбора первой обратной связи. На этом этапе команду App in the Air покинули трое из пяти человек: Аннаков остался вместе с техническим директором сервиса — Сергеем Прониным.

  Сергей Пронин

  «В 2012 году казалось, что можно создать любое приложение, и оно обязательно взлетит — надо только загрузить в App Store или Google Play. Эти завышенные ожидания, конечно же, разбились о реальность», — говорит сооснователь App in the Air.

  Аннаков занимался службой поддержки и развитием продукта, а Пронин — серверами компании и разработкой приложения на iOS. Спустя некоторое время к App in the Air присоединились сотрудники, которые помогали поддерживать сервис, вели аналитику и сбор данных.

  «После релиза мы сидели в квартире, в которой располагался офис, изучали поведение пользователей, читали отзывы и правили ошибку за ошибкой. Затем выпускали обновленную версию сервиса и видели, как количество багов уменьшается», — рассказывает Аннаков.

  Первые пользователи узнали о App in the Air из упоминаний в ряде изданий и на площадках вроде Flyertalk, Reddit и PhoneArena. На первые рекламные платные публикации команда проекта потратила около $20 тысяч. Благодаря этому, по словам Аннакова, удалось «подбросить» продукт и получить интерес со стороны пользователей и других изданий.

  Редкая информация и награды

  Один из первых пользователей App in the Air — канадский предприниматель — проводит в самолетах 500 часов в год. Для сравнения: бортпроводники в среднем в год тратят 500-700 часов на полеты.

  Клиент посоветовал команде проекта сконцентрироваться на так называемых авиагиках, а не на всех подряд. Также он посоветовал им включить особые функции, которые не понятны большинству обычных пользователей, но представляют интерес для любителей путешествовать самолетом.

  По словам Аннакова, в США 81% скачиваний App in the Air совершают пользователи, которые летают не более трех-четырех раз в год. Они не представляют интерес для сервиса.

  Оставшиеся 19% — пассажиры, которые совершают более 10 перелетов в год. В США эта категория клиентов дает авиакомпаниям 35% дохода. Эти же пассажиры совершают 60% всех перелетов. Именно на них ориентируется App in the Air и старается их удержать, рассказывает предприниматель.

  В ход идут такие опции, как статистика перелетов, доска соревнований с другими пользователями, награды за то или иное достижение, возможность создать видео с перемещениями за год и другие.

  Пользователи App in the Air любят соревноваться между собой и сравнивать количество наград, говорит Аннаков.

  Бейджи, которые даются пользователю за достижения

  Приложение награждает клиентов бейджами за такие успехи, как полет на пяти разных моделях самолета одного производителя, посещение новой страны, 100 часов в воздухе, полет red eye (вылет и прилет в ночь) и так далее.

  Однажды мне написал один известный российский предприниматель, который сказал, что ему пришлось поменять рейс, чтобы получить ачивку за использование разных моделей Boeing. Вот такие пользователи нам и нужны.

  Байрам Аннаков

  Клиенты App in the Air также пользуются редкой информацией, которую отображает приложение про тот или иной полет. Например, один из пользователей обращает внимание на tail number самолета — код, который прикреплен к самолету и не меняется в зависимости от смены авиалиний.

  Он знает, на каких бортах с определенным номером есть специальные крючки для вешалок — ему это важно, так как летает с чехлами для костюмов и не хочет помять одежду, убирая её в багажный отсек над головой.

  «Сколько вы знаете людей, которым важно знать tail number? Одного, видимо», — говорит Аннаков.

  Поддержка и новые функции

  Создатель App in the Air рассказывает, что продукт стало не стыдно показывать целевой аудитории только в 2013 году. Компания сделала службу поддержки и сбор обратной связи одним из важных направлений развития бизнеса.

  Сейчас члены команды, которая за 2017 год выросла до 21 человека, периодически работают в поддержке, чтобы понять нужды пользователей. «Именно поддержка вытащила наш продукт», — говорит Аннаков.

  Мы не только получали отзывы через приложение, но и проводили время в аэропортах, записывая поведенческие особенности пользователей.

  Например, пожилой пассажир с плохим зрением не мог считать информацию с табло аэропорта и попросил кого-то другого посмотреть его вылет. Безусловно, имея смартфон, можно легко решить эту проблему.

  Байрам Аннаков

  Одной из функций, которую предлагали пользователи, стала синхронизация с календарем владельца смартфона. Аннаков поясняет, что когда пассажиры летают часто, например, три раза в неделю, то могут забыть или перепутать время рейса. Наличие информации не только в приложении, но и в календаре позволяет вовремя напомнить о готовящейся поездке.

  Также благодаря отзывам клиентов появились уведомления о ключевых событиях — открытии и закрытии регистрации и времени начала и конца посадки на борт. Приложение присылает пользователю push-уведомления.

  Еще одну просьбу пользователей — добавить информацию из программ лояльности — удалось исполнить только в 2016 году. Сейчас App in the Air отображает количество баллов и срок их истечения во всех крупных авиакомпаниях кроме трех американских — United, Delta и American Airlines.

  Сложность проекта заключалась в юридических вопросах. Аннаков объясняет, что авиакомпании считают данные программ лояльности своей собственностью, а не пассажиров.

  Доступ к этой информации App in the Air получил, заключив соглашение с компанией Points.com, которая разрабатывает софт для систем накопления летных миль. С некоторыми авиакомпаниями удалось договориться напрямую. Сейчас App in the Air ведет переговоры с United, Delta и American Airlines.

  «Если не поможет выгодный обмен, то попрошу наших пользователей создать петицию на Change.org, для которой мы быстро наберем более 100 тысяч подписей», — шутит Аннаков.

  Сотрудничество с авиакомпаниями

  Под выгодным обменом сооснователь сервиса подразумевает доступ компаний к отзывам о полетах, которые собирает App in the Air. Стартап запустил эту функцию в конце 2017 года. За два месяца сервис собрал 20 тысяч отзывов.

  В приложении можно ответить на вопросы по четырем критериям и по желанию оставить текстовый комментарий. По словам Аннакова, треть пользователей пишет, что им понравилось или не понравилось.

  Чаще всего клиенты жалуются на опоздание самолета и при этом указывают причину (например, службы аэропорта долго не подавали трап). На втором месте рейтинга жалоб — возраст самолета. Сооснователь App in the Air отмечает, что стартап выявил зависимость оценки полета от срока эксплуатации борта.

  Кроме того, пользователи высказывают недовольство из-за размера шага между креслами и отсутствия (или плохой работы) Wi-Fi.

  С помощью отзывов компании смогут понимать, что им улучшать и стоит ли вообще предпринимать усилия в зависимости от того, как часто клиент пользуется услугами авиаперезвочика.

  Авиакомпании тратят миллиарды долларов на улучшения, но онлайн-сервисы отображают полеты вместе с другими перезвочиками, а в доступных пользователю параметрах остаются только цена и продолжительность рейса.

  Это всё равно, что показать рядом два смартфона и дать информацию только об их цене и весе.

  Авиалинии хотят дифференцировать продукты и показать пользователю, что инвестируют в свои сервисы и услуги. Компаниям нужно понимать, оправдываются ли их вложения.

  Байрам Аннаков

  Каждую неделю аналитик App in the Air показывает интересные отзывы за неделю. Один из клиентов жаловался, что был готов заплатить за еду на борту British Airways, но бортпроводник не дошел до него с терминалом, так как устройство было всего одно на весь борт.

  «Сколько авиалиний знают о том, что вот так упускают выгоду? Эти данные очень интересны и повышают ценность нашей компании», — отмечает Аннаков.

  Продвижение

  Сейчас 50-55% трафика сервису приносят магазины приложений App Store и Google Play. Площадки периодически включают App in the Air в разные подборки.

  Остальная часть аудитории приходит через разные рекламные каналы, которые стартап тестирует. App in the Air, по словам Аннакова, готовится к активной рекламной кампании и проверяет стоимость привлечения клиентов в том или ином сервисе.

  Пока что преимущество у продуктов Apple и Google. Механизмы продвижения Facebook Аннаков назвал дорогими, а Twitter — странными. При этом сервис микроблогов позволяет настроить таргетинг на пользователей конкурирующих сервисов и пассажиров авиакомпаний.

  Часть трафика App in the Air приходит через агрегаторы для покупки билетов Aviasales и Wego, с которыми стартап заключил партнерства. При этом западные сервисы отказываются работать с ассистентом, так как видят в нем конкурента своим приложениям. Хотя App in the Air не продает билеты, указывает Аннаков.

  Подписка и дополнительные услуги

  Сооснователь App in the Air не раскрывает количество пользователей, но говорит, что клиент сервиса есть на каждом рейсе Lufthansa, хотя доля проекта на рынке пассажиропотока — 0,5%. До конца 2018 года стартап собирается увеличить её до 3-5%.

  Также Аннаков держит в тайне выручку приложения, добавляя, что этого хватает на разработку продукта и содержание трех офисов — в Москве, Барселоне и Лос-Анджелесе.

  90% выручки составляет подписка на сервис, которая в среднем обходится клиенту в $35 в год. При этом пользователи могут купить бессрочную подписку за $70. Аннаков отмечает, что эта опция не для дополнительного привлечения пользователей, а для создания лояльной долгоживущей аудитории.

  10% от дохода App in the Air составляет продажа дополнительных сервисов. Например, вход в бизнес-зал за $25-35. Услугу удалось реализовать благодаря партнерству с сервисом LoungeBuddy, который предоставляет доступ в бизнес-залы аэропортов. Себе App in the Air оставляет комиссию, а основная часть средств идет партнеру.

  Кроме того, App in the Air совместно со швейцарской страховой компанией реализовала для клиентов в Великобритании сервис, который позволяет получить денежное вознаграждение при задержке рейса.

  Стоимость услуги — около £5 в зависимости от рейса. В случае задержки самолета на полчаса пользователю на счет PayPal сразу же приходит £100 в качестве компенсации. Услуга не требует дополнительных документов — всё происходит автоматически.

  По мнению Аннакова, благодаря сервису пассажиры начинают «играть» с авиалиниями, пытаясь угадать — задержится самолет или нет.

  Глобальная цель App in the Air — предоставить клиенту доступ ко всем услугам, которые связаны с перелетами. По словам Аннакова, до конца 2018 года ассистент получит некоторые новые возможности, подробности которых он не раскрывает.

  Похожие публикации:

  1. Как убрать прицел с экрана монитора
  2. Какие метрики важно отслеживать после запуска приложения
  3. Какие слова называют служебными информатика
  4. Сколько омов в 0 25 ком