AACsearch
Справочник

Гайд по позиционированию

Каноническое позиционирование AACSearch OS. Эта страница держит блог, comparison-страницы, маркетинг и кейсы в рамках Search Operating System.

AACSearch — это Search Operating System для product-grade discovery. Не search-as-a-service, не hosted search, не generic search API, не "альтернатива Algolia". Эта страница — источник истины. Любая копия в маркетинге, блоге, comparison и кейсах должна сводиться сюда.

Каноническая формулировка

AACSearch OS — Search Operating System для product-grade discovery.

Эту фразу (или близкую локализацию) используем в начале сравнительных страниц, кейсов и Hero-блоков, где нужен tagline. В сомнениях — выбираем её, а не выдумываем новую.

Что это значит в тексте

  • Подлежащее каждого предложения — домен продукта, а не модель доставки. "AACSearch индексирует, ранжирует и отвечает по продуктовым данным" — а не "AACSearch — это hosted search service, который…".
  • Сценарии, а не функции. Ведём с того, что читатель шипит: discovery товаров, AI-ответы, мульти-арендные сторфронты, базы знаний. Каталог функций (синонимы, курации, scoped-токены) — поддерживающие детали.
  • Self-hosted ограничен. Cloud SaaS — живая поверхность. Self-hosted — Roadmap (v1.0) по Claim status. Comparison- страницы вокруг "self-hosted" должны ссылаться на роадмап, а не вид того, что это уже доступно.
  • Без формата "альтернативы". "Альтернатива Algolia" / "альтернатива ElasticSearch" — реактивное позиционирование. Сравнительные страницы — ок, но они нейтральные таблицы фактов, а не эссе "почему X — плохо".

Запрещённые формулировки в новой копии

Не писатьЗаменять на
"Search-as-a-service" / "Поиск как услуга""Search Operating System"
"Hosted search service" / "Хостед поиск""AACSearch cloud" (когда важна модель доставки)
"Альтернатива Algolia""AACSearch vs Algolia" с нейтральной таблицей фактов
"Generic search API" / "Универсальный API""Search Operating System с first-class API"
"Powered by Typesense""Поверх Typesense storage layer" — только когда это действительно важно

Существующие посты, нарушающие эти правила, имеют legacy: true во frontmatter и показывают баннер, ведущий сюда. Новые посты НЕ должны нести этот флаг.

Канонические CTA по поверхностям

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

  • Покупатель / decision-maker/contact (поговорить с sales) или /pricing (планы).
  • Инженер, который оценивает/docs/getting-started (Quickstart) или /docs/search-api (тур по Search API).
  • Существующий клиент, который масштабируется/dashboard или /docs/operations.
  • Читатель, интересующийся одним концептом → соответствующая страница /docs/overview/* или /docs/reference/*.

Если у поста нет одного из этих CTA — читателю некуда конвертиться. Минимальный уровень — "Открыть документацию →" с конкретным docs-URL.

Правила comparison-страниц

  1. Начинаем с работы покупателя, а не имени конкурента.
  2. Используем нейтральную таблицу фактов — функция × продукт × да/нет/частично.
  3. Цитируем источник сравнения (URL документации вендора с датой). Устаревшие цитаты ловятся в Docs quality gates.
  4. Закрываем каноническим CTA, не "купоном на переход с X".

В сомнениях

Если сомневаетесь, что копия попадает в этот гайд — не публикуйте. Заведите issue против маркетинга с тегом positioning и приложите драфт.

On this page