Каналы поставки: свой сайт, маркетплейсы облаков, партнёры

Команда продавала систему мониторинга через свой сайт: карта, оферта, доступ через минуту после оплаты. Пришёл крупный клиент — и сделка встала. Не из-за цены и не из-за функций: у клиента подписано трёхлетнее обязательство потратить определённую сумму в облаке, а бюджет на «прочее ПО» исчерпан. Закупка сказала фразу, знакомую всем, кто продавал в корпоративный сегмент: «если вы есть в маркетплейсе нашего облака, покупаем завтра; если нет — заводите нового поставщика, это квартал».

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

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

Канал — это три потока, а не один

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

Потоки расходятся: артефакт может ехать напрямую от вас, деньги — через площадку, отношения — принадлежать партнёру. Каждое расхождение даёт новую точку отказа и новую строку в договоре.

Один вывод из матрицы стоит выделить, потому что вокруг него строится вторая половина главы. Колонка «выдача прав» почти всегда остаётся вашей. Площадка присылает факт («аккаунт X оформил подписку на план Y»), а решение («этому тенанту доступен план Y до такой даты») принимает ваш код. Как только вы разрешите чужой системе писать права напрямую в базу продукта, у вас появится столько источников истины, сколько каналов, и они разъедутся в первый же месяц.

Общая рамка: чем канал платит и что берёт взамен

Считать канал полезно на одной сделке за период. Пусть p — цена, которую платит покупатель, c — суммарная доля канала (комиссия площадки, эквайринг, скидка партнёру), s — прямая себестоимость обслуживания одного получателя, a — стоимость привлечения через этот канал. Задержка выплаты — тоже расход, просто незаметный: если деньги приходят через d суток, а стоимость капитала r годовых, честная величина такая:

$$ n = p \cdot (1 - c) - s - a \qquad n_{\mathrm{eff}} = n - p \cdot (1 - c) \cdot r \cdot \frac{d}{365} $$

Пример: подписка 60 000 рублей в год, комиссия площадки 10 процентов, себестоимость 9000 рублей, привлечение 4000 рублей, выплата через 75 суток, стоимость денег 25 процентов годовых. Тогда чистая сумма на сделке 60000 · 0,9 − 9000 − 4000 = 41 000 рублей, поправка на задержку 54000 · 0,25 · 75/365 ≈ 2774 рубля, итог около 38 200. На одной сделке разница невелика, на сотне — это замороженный оборотный капитал, из-за которого растущие компании кассово разрываются.

Дальше вопрос не «какой канал выгоднее», а «что канал добавляет сверх того, что и так продалось бы». Пусть через канал пришло N сделок, доля θ из них купила бы напрямую (каннибализация), F — постоянные расходы на поддержание канала: интеграция, сертификация, менеджер партнёров, поддержка листинга.

$$ \Delta = N \cdot n_{k} - \theta \cdot N \cdot n_{d} - F $$

Если приращение отрицательно, канал не «плохой» — он просто перекладывает ваши же продажи в чужой карман. Отсюда первый вопрос про любой канал: какой спрос он приносит такого, которого у вас нет? Юнит-экономика вокруг этого счёта — в бизнес-треке, готовность платить — в продуктовом.

Свой сайт: весь контроль и весь труд

Покупателю он даёт прямую цену без наценки, полный набор тарифов, ваши условия возврата, мгновенный доступ. Для мелких и средних покупок это лучший канал: между «я хочу» и «я пользуюсь» ничего нет. Не даёт доверия («кто эти люди и будут ли они через год»), процедуры («нам нужен счёт, акт и договор»), доступа к чужому бюджету и снятых за покупателя вопросов налога и безопасности.

Вам он стоит не «страницы с ценами», а как минимум вот этого набора узлов:

Ключевое обязательство прямого канала: вы продавец записи (merchant of record) — договор с покупателем ваш, претензия придёт вам, налог с продажи ваш. Как выглядят сформулированные обязательства, видно на этом портале: оферта, условия возврата, политика ПДн. Это не «юридический раздел», а список того, что обязан уметь код: зафиксировать принятую редакцию оферты, вернуть деньги на тот же инструмент, удалить данные по запросу. Инженерное ядро канала при этом — разделение платежа и права: платёж прошёл — факт платёжной системы, право выдано — ваше решение. Между ними обязана быть идемпотентная операция, иначе повторный вебхук выдаст вторую подписку, а сетевой таймаут — ни одной.

def apply_payment(conn, fact) -> str:
    """Выдаёт право ровно один раз на событие. fact пришёл из канала и может
    прийти повторно, с опозданием или не по порядку."""
    with conn.transaction():
        # 1. Журнал событий — защита от повторов: арбитр не наш if, а уникальный
        #    индекс на (channel, event_id).
        if conn.execute(
                """INSERT INTO channel_events (channel, event_id, external_id, received_at)
                   VALUES (%s, %s, %s, now())
                   ON CONFLICT (channel, event_id) DO NOTHING RETURNING 1""",
                (fact.channel, fact.event_id, fact.external_id)).fetchone() is None:
            return "duplicate"
        # 2. Побеждает более позднее по времени ИСТОЧНИКА: очередь легко
        #    переставляет отмену и апгрейд местами.
        cur = conn.execute("SELECT source_time FROM entitlements "
                           "WHERE channel = %s AND external_id = %s FOR UPDATE",
                           (fact.channel, fact.external_id)).fetchone()
        if cur and cur["source_time"] >= fact.occurred_at:
            return "stale"
        # 3. Право. Срок считается от времени источника, иначе задержка очереди
        #    молча дарит клиенту лишние часы обслуживания.
        conn.execute(
            """INSERT INTO entitlements (channel, external_id, account_ref, plan,
                                         seats, valid_until, source_time)
               VALUES (%s, %s, %s, %s, %s, %s, %s)
               ON CONFLICT (channel, external_id) DO UPDATE
                 SET plan = EXCLUDED.plan, seats = EXCLUDED.seats,
                     valid_until = EXCLUDED.valid_until,
                     source_time = EXCLUDED.source_time""",
            (fact.channel, fact.external_id, fact.account_ref, fact.plan, fact.seats,
             fact.occurred_at + timedelta(days=fact.period_days), fact.occurred_at))
        return "granted"

Сложность — O(1) на событие (два индексных обращения), память O(1); журнал растёт линейно и требует политики усечения. Теория этого места — идемпотентность и доставка сообщений.

Риск, который недооценивают: споры по картам. Цифровой товар с мгновенной выдачей — любимая мишень для оплаты краденой картой: держатель оспаривает операцию, банк списывает деньги обратно и берёт сбор за разбор независимо от исхода, а при доле споров выше установленного платёжной системой порога эквайер поднимает тариф или отключает вас. Отсюда требования к коду: логировать доказательства поставки (время выдачи, IP, принятая редакция оферты, факт скачивания), уметь мгновенно отзывать право, держать правила антифрода. Окно оспаривания измеряется месяцами, поэтому «деньги пришли» и «деньги ваши» — разные события.

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

Маркетплейсы облаков: продажа в чужой уже одобренный бюджет

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

Покупателю он даёт засчитывание покупки в обязательство по расходам перед облаком (клиент, обещавший потратить сумму за три года, предпочтёт продукт, который эту сумму «съедает»), единый счёт вместо нового договора, пройденную процедуру закупки и частично снятые вопросы безопасности за счёт базовых проверок площадки; экономия измеряется неделями, а иногда кварталом. Вам он даёт доступ к деньгам, которые вы иначе не получили бы, и механизм приватного предложения — индивидуальные цена и условия для конкретного клиента, оформленные через площадку; для зарубежных сделок это иногда единственный способ продать, не открывая там юрлицо. Есть ещё программы совместных продаж, где продавцы облака приводят вам сделки, но вход туда требует сертификации и живого менеджера с вашей стороны.

Форма листинга — первое инженерное решение:

Самая интересная и опасная — SaaS-подписка: она вводит в вашу систему чужой асинхронный источник правды.

Из этой последовательности вырастают все типовые аварии.

• Токен одноразовый и короткоживущий. Открыли ссылку дважды или через сутки — обмен не пройдёт. Нужна страница «не получилось, вот что делать» и ручное восстановление связки.
• Оборванная регистрация. У площадки подписка есть, у вас аккаунта нет; клиент уверен, что купил, и счёт ему выставят. Лечится сверкой и очередью «висящих» подписок, по которым поддержка пишет клиенту первой.
• Уведомления приходят дважды и не по порядку. Отмена может прилететь раньше сделанного до неё апгрейда. Правило: применять по времени источника, хранить журнал, не полагаться на порядок доставки.
• Метрики потребления. У API есть окно приёма записей задним числом, лимит на объём вызова и требование уникального ключа. Пропустили час — деньги за него не выставятся никогда: это прямая потеря выручки, а не «мелкая ошибка мониторинга».

def report_usage(client, records, clock):
    """Пакетирование по лимиту API, повтор только неуспешных, явный учёт записей,
    опоздавших к окну приёма. BATCH и WINDOW_H берутся из документации площадки."""
    BATCH, WINDOW_H, to_retry, dropped = 25, 6, [], []
    for batch in chunked(records, BATCH):
        fresh = [r for r in batch
                 if (clock.now() - r.timestamp).total_seconds() < WINDOW_H * 3600]
        dropped += [r for r in batch if r not in fresh]   # опоздали: деньги потеряны
        for item in (client.batch_meter_usage(records=fresh)["Results"] if fresh else []):
            status = item["Status"]
            if status == "Success":
                mark_reported(item["UsageRecord"])
            elif status in ("CustomerNotSubscribed", "DuplicateRecord"):
                mark_final(item["UsageRecord"], status)  # повтор бесполезен
            else:
                to_retry.append(item["UsageRecord"])     # лимиты и временные сбои
    if dropped:
        alert("usage_records_dropped", count=len(dropped))  # инцидент, а не лог
    return to_retry, dropped

Сложность — O(n / BATCH) вызовов на n записей, память O(BATCH). Следствие: агрегируйте потребление до отправки, иначе сырое событие на каждый запрос упрётся в лимиты и превратит биллинг в узкое место. Подробнее — в ценообразовании и биллинге.

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

Состояния orphan и drift — не экзотика, а нормальный режим интеграции с чужой системой. Если их нет в вашей модели, они всё равно возникнут, просто в виде тикетов в поддержку. Про режимы отказа интеграций — failure modes.

Комиссия: механизм, а не таблица. Площадка удерживает долю с каждой сделки. Исторически базовая ставка публичных листингов у крупных облаков была около двадцати процентов; затем площадки начали конкурировать за поставщиков и снижать её — для приватных предложений, крупных контрактов и отдельных категорий ставки опустились до единиц процентов. На середину 2026 года разумно ожидать диапазон от единиц процентов на крупных приватных сделках до примерно двадцати на мелких публичных подписках, но опираться надо на действующие условия программы: за последние пять лет они менялись у всех крупных площадок неоднократно. Второй параметр важнее первого: с каким коэффициентом покупка засчитывается в обязательство клиента по расходам — полностью или частично. Именно он определяет, насколько сильно клиент хочет купить через маркетплейс.

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

Сроки как порядок величин: подготовка листинга и документов — недели; проверка площадкой — от нескольких дней до нескольких недель с итерациями по замечаниям; первая выплата — второй-третий месяц после первой продажи. Это проект на квартал, а не задача на спринт.

Пакетные менеджеры и реестры: канал без денег

Homebrew, apt и rpm-репозитории, winget, Flathub, реестры контейнеров, npm, PyPI, Maven Central, репозитории чартов — каналы распространения без биллинга. Денег в них нет, зато есть то, что деньгами не покупается: путь установки в одну команду и доверие среды, где пользователь уже находится. Ему это даёт установку без похода на сайт, обновления вместе с системой, проверенную подпись и единый способ удаления — для инфраструктурного инструмента решающий фактор выбора.

Вам это стоит чужих правил упаковки: у каждого реестра свои требования к метаданным, лицензиям, зависимостям и способу сборки, а часть площадок принимает только свободные лицензии — выбор из главы про лицензии прямо открывает или закрывает канал. Версия, которую видит пользователь, вам не подчиняется: в стабильных дистрибутивах пакет отстаёт на годы, а баг-репорты придут вам. Обязательства — подпись артефактов и воспроизводимость сборки: цепочка поставок ПО, контейнеры и реестры и глава Упаковка и установка. Отдельная тема — переупаковка третьими лицами: кто-то соберёт ваш проект под свой дистрибутив, соберёт неправильно, и разбираться придут к вам. Управляемый ответ — официальный репозиторий, явная политика поддерживаемых версий и заметная строчка «эти сборки официальные, остальные — нет».

Партнёры: продаёт кто-то другой, отвечаете всё равно вы

Партнёрские схемы различаются не «уровнем близости», а ответами на четыре вопроса: кто выставляет счёт конечнику, кто владеет отношениями, кто держит первую линию поддержки, кто рискует неплатежом.

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

Механика, которую вводят до первого партнёра:

• Регистрация сделки. Партнёр заявляет клиента, получает защиту на срок и специальную цену. Без этого два партнёра и ваш сайт придут к одному клиенту с тремя ценами.
• Единый прайс и ценовой пол. Цена на вашем сайте публичная, партнёр покупает со скидкой. Продаёте дешевле партнёра — канал умирает за месяц.
• Демонстрационные лицензии с запретом перепродажи, ограниченным сроком и пометкой в системе прав, иначе они утекут в продакшн.
• Отзыв прав при неоплате. Права выданы конечнику, а деньги ещё идут: договоритесь заранее, что происходит при просрочке, и сделайте отзыв технически возможным.

Инженерная часть партнёрского канала — это API и роль, а не доступ в вашу админку. Партнёру нужно создавать клиента, продлевать и менять права, видеть потребление своих клиентов и только своих. Это многотенантная задача из главы Многотенантность с дополнительным уровнем иерархии «партнёр — клиент — пользователи» и правилом, что партнёр не видит данные конечных пользователей, если это не оговорено отдельно. Сам канал полезно описать конфигурацией, а не знанием в голове менеджера:

channels:
  - id: self                          # прямой канал: продавец записи — мы
    kind: direct
    merchant_of_record: us
    price_list: public
    discount_max: 0.10                # предел скидки без согласования
    payout_lag_days: 2
    entitlement_source: payment_provider

  - id: cloud-marketplace-eu
    kind: cloud_marketplace
    merchant_of_record: platform
    price_list: public                # цена видна всем, включая конкурентов
    commission_note: "ставка по действующей программе, проверять перед пересмотром цен"
    payout_lag_days: 75
    entitlement_source: platform_events
    reconcile: {schedule: "daily 03:00", on_drift: open_incident}

  - id: reseller-nordics
    kind: reseller
    merchant_of_record: partner
    price_list: partner_tier_2
    discount_max: 0.28                # маржа партнёра зашита в прайс-лист
    payment_terms_days: 45
    deal_registration: required
    revoke_on_overdue_days: 30        # через сколько суток просрочки отзываем права
    support_tier: partner_first_line

OEM и встраивание ломают всё сразу: код уезжает внутрь чужого продукта, конечный пользователь о вас не знает, учёт идёт по отчётам партнёра, которые надо уметь проверять, активация часто обязана работать без интернета. И главное — лицензии ваших зависимостей едут вместе с вами. Копилефтная библиотека внутри продукта, который партнёр ставит клиенту на завод, означает обязанность предоставить исходники конечному получателю, а получатель тут не партнёр, а клиент партнёра. Механику разбирает глава про лицензии на случае инстанса it-tools под GPL-3.0: триггером обязательства стала сама передача объектного кода, а не продажа. В OEM-канале такая передача происходит на каждой поставке.

Одна система прав, много каналов

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

Три свойства делают эту модель пригодной для эксплуатации. Внешний идентификатор живёт рядом с правом, а не вместо него: пара (channel_id, external_id) уникальна и связывает чужую запись с вашей, а один аккаунт может иметь права из разных каналов — это нормально, и правило слияния должно быть записано (обычно места суммируются, план берётся максимальный, срок — максимальный из активных). Время источника хранится отдельно от времени получения, иначе нельзя корректно применять события, пришедшие не по порядку. Ежедневная сверка — обязательный процесс, не «на всякий случай», а часть эксплуатации.

-- Сверка: что канал считает активным против того, что считаем мы.
-- channel_snapshot заполняется выгрузкой из API площадки перед запуском.
WITH ours AS (SELECT external_id, plan, seats FROM entitlements
              WHERE channel_id = 'cloud-mp-eu' AND state = 'active' AND valid_until > now()),
   theirs AS (SELECT external_id, plan, seats FROM channel_snapshot
              WHERE channel_id = 'cloud-mp-eu' AND snapshot_date = current_date)
SELECT coalesce(o.external_id, t.external_id) AS external_id,
       CASE WHEN t.external_id IS NULL THEN 'обслуживаем без подписки'  -- отдаём даром
            WHEN o.external_id IS NULL THEN 'подписка без аккаунта'     -- берём деньги зря
            WHEN o.plan  <> t.plan     THEN 'разошёлся план'
            WHEN o.seats <> t.seats    THEN 'разошлось число мест'
       END AS drift_kind
FROM ours o FULL OUTER JOIN theirs t USING (external_id)
WHERE t.external_id IS NULL OR o.external_id IS NULL
   OR o.plan <> t.plan OR o.seats <> t.seats;

Две первые строки результата стоят денег в разные стороны: «обслуживаем без подписки» — вы дарите продукт; «подписка без аккаунта» — клиенту выставляют счёт за то, чем он не пользуется, а это возврат, жалоба площадке и падение рейтинга продавца. Обе ситуации должны создавать задачу с ответственным, а не строку в логе. Типовые аварии мультиканальности:

1. Двойная покупка. Клиент купил на сайте, потом закупка оформила подписку в маркетплейсе: две активные подписки и двойной счёт. Лечение — поиск дублей по домену почты и налоговому идентификатору при выдаче права плюс явное правило слияния.
2. Отмена, которая не долетела. Уведомление потерялось, вы обслуживаете бесплатно месяцами. Лечит только сверка.
3. Ретроактивное изменение. Площадка присылает уменьшение числа мест задним числом, а счёт уже выставлен. Нужна политика: пересчитываем или фиксируем прошлое.
4. Партнёр не продлил, а клиент работает. Технический отзыв должен существовать до того, как понадобится.
5. Разъехавшиеся валюты и налоги. Одна подписка в трёх каналах пришла в трёх валютах с тремя правилами налога. Хранить надо исходную валюту и признаки, применённые в момент продажи, — восстановить их потом невозможно.
6. Конфликт каналов. Ваша распродажа обесценила прайс партнёра в день подписания контракта. Это не «маркетинг ошибся», а отсутствие единого прайса.

Как выбирать канал: решение, а не мода

Порядок открытия каналов почти всегда один: каждый следующий требует работающего предыдущего. Сначала свой сайт — там вы учитесь продавать и выдавать права; затем, по спросу, маркетплейс, если клиенты сами просят, или партнёры, если они сами приходят. Канал, открытый потому, что «так делают все», съедает инженерное время и не приносит спроса. Признак настоящего спроса простой: вам уже трижды сказали «мы бы купили, но не можем — вот так, как вы продаёте». Есть и каналы, где правила задаёт не площадка, а закон: государственные закупки с их процедурой, требованиями к поставщику и, в ряде стран, требованием присутствия продукта в национальном реестре ПО. Оценивать их надо той же рамкой, а конкретные требования уточнять у юриста.

Что спросить у юриста (и не решать самому)

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

1. Кто продавец записи в каждом канале и кто отвечает за налог с продажи в юрисдикции покупателя? Меняется ли ответ, если покупатель из другой страны?
2. Что стандартный договор площадки возлагает на вас в части гарантий, ответственности и ограничения убытков, и что будет при претензии конечного клиента?
3. Можно ли по договору с площадкой продавать тому же клиенту напрямую и на каких условиях? Что происходит с клиентом при продлении?
4. Какие в партнёрском договоре условия о территории, эксклюзивности и сроке; как он расторгается и что происходит с клиентами партнёра после расторжения?
5. Допустима ли в вашей юрисдикции разница цен между каналами и по территориям? Где граница между политикой прайса и ограничением конкуренции?
6. Экспортные и санкционные ограничения: кому нельзя поставлять и как это проверять технически (см. Ограничения)?
7. Партнёр по отношению к персональным данным конечных пользователей — обработчик или самостоятельный оператор, и каким документом это зафиксировано? (Приватность и соответствие требованиям.)
8. Как партнёр вправе использовать ваши товарные знаки и что обязан снять после расторжения?

Хорошая формулировка отличается от плохой наличием фактов: не «а можно ли нам в маркетплейс», а «мы отдаём площадке идентификатор аккаунта и объём потребления, площадка выставляет счёт от своего имени клиенту в другой стране, деньги приходят через 75 суток за вычетом комиссии — кто здесь продавец и чей налог». Про договорные обязательства в принципе — контракты, живой пример — раздел /legal этого портала.

Типичные ошибки

• Считать канал маркетингом. Он меняет модель данных и добавляет асинхронный источник правды: это работа инженеров, а не только продаж.
• Позволить каналу писать права напрямую. Через два канала у вас две истины, через три — постоянные расхождения. Права выдаёт только ваш сервис прав.
• Не сделать сверку. Её отсутствие замечают по жалобе клиента или недостаче в отчёте, поздно.
• Забыть про кассовый разрыв. Права выданы сегодня, деньги придут через два месяца, а зарплату платить в конце этого: деньги и риск.
• Продавать на своём сайте дешевле партнёра. Способ потерять канал, потратив на него полгода.
• Игнорировать лицензии зависимостей при выходе в канал. Копилефт в OEM-поставке или в мобильном магазине способен закрыть канал целиком.
• Не агрегировать потребление. Лимиты API площадки превращаются в потерянную выручку.
• Считать комиссию единственным параметром. Коэффициент зачёта в обязательство клиента, срок выплаты и правила продления влияют на деньги не меньше процента комиссии.
• Открывать канал без ответственного. Нужен человек, к которому приходят расхождения сверки, и инженер, знающий API канала.

Мини-итог

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

Инженерный минимум для любого канала: единственный сервис прав, идемпотентная обработка событий по времени источника, ежедневная сверка с чужой системой, технически возможный отзыв прав и записанное правило разрешения конфликтов. Остальное — переговоры, и приходить на них стоит с посчитанной чистой суммой на сделке, а не с ощущением. Чек-лист перед открытием канала:

1. Назван спрос, которого нет в текущих каналах, и он подтверждён отказами реальных покупателей.
2. Посчитана маржа на сделке с учётом комиссии, себестоимости, привлечения и задержки выплаты.
3. Решено, кто продавец записи и чей налог; вопрос задан юристу в виде фактов, а не общих слов.
4. Спроектирован адаптер канала: нормализация событий, идемпотентность, время источника.
5. Сверка написана и поставлена в расписание; расхождение создаёт задачу с ответственным.
6. Есть технический отзыв прав и правило, когда он применяется.
7. Единый прайс и правила скидок записаны до появления первого партнёра.
8. У канала есть владелец с именем и инженер, знающий его API.

Источники

• Руководство продавца AWS Marketplace, включая интеграцию SaaS и приватные предложения — https://docs.aws.amazon.com/marketplace/latest/userguide/what-is-marketplace.html
• Коммерческий маркетплейс Microsoft: типы предложений и транзакционные возможности — https://learn.microsoft.com/en-us/partner-center/marketplace-offers/marketplace-publishers-guide
• Google Cloud Marketplace для поставщиков — https://cloud.google.com/marketplace/docs
• Правила приёма формул в Homebrew как пример требований пакетного канала — https://docs.brew.sh/Acceptable-Formulae
• Документация Flathub для издателей приложений — https://docs.flathub.org/
• Механика споров по картам и доказательства поставки — https://stripe.com/docs/disputes
• Рабочие документы этого портала как пример обязательств прямого канала: оферта, возвраты, политика ПДн

Что дальше

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