shield_lock
金大哥
← 返回 Skill 列表
extension
分类: 内容与媒体API Key 暂未确认

品牌感知定位图分析师

上传品牌×属性问卷表先做数据形态体检，产出感知定位图、维度商业命名、贡献度与可靠性披露的定位报告。

person作者: erzat1986hubOpenAPI
download下载资源包

zvex 品牌感知定位图分析师

把品牌方的问卷数据（「品牌×属性」勾选汇总、一行一个受访者的作答明细、或评分+标签混合表，Excel、CSV、直接粘贴都行）变成一份感知定位决策报告：消费者把每个品牌感知成什么样、每个维度怎么用业务语言命名、谁和谁挤在同一竞争簇、哪块感知空白值得追、新品上市怎么挂图跟踪。先在对话里体检与路由；要完整分析报告时走引擎深度交付；报告结论先行、每个数字可溯源、可靠性限制如实披露。

文档分层：本文件是使用层（能力、示例节选、边界与 FAQ）；调用报文、参数表与报错对照在 references/api.md。

能力

| 能力 | 说明 | 产出方式 | |---|---|---| | 数据形态体检 | 表型三分类判定（列联汇总=品牌×属性非负计数/占比；受访者明细=一行一人分类作答；混合表=数值评分+分类标签）；非负与口径核对（计数与占比不混用、同义属性归并、全勾/全不勾与无效问卷排除口径——排除口径改变分母，全部解释率随之改变）；稀疏预检（格子提及量过稀结构不稳，低提及属性建议挂补充列） | 对话内完成 | | 方法路由诊断 | 按形态路由而非按偏好：恰好两列→对应分析；纯分类多列→多对应分析（默认特征值校正——指示矩阵会系统性低估惯量，不校正的方差解释率是失真的）；数值+分类混合→混合数据方法（数值标准化、分类按模态占比重缩放，影响力平衡）；题组分组→多表方法（组内同质、组间加权平衡，回答哪个题组主导结构）；路由依据写进口径声明 | 对话内完成 | | 完整感知定位图报告 | 维度盘（每维度方差解释率、累计解释率、贡献度 Top 属性、两极商业命名）；品牌落位解读（业务语言+竞争簇标示+与最近竞品的感知距离）；可靠性披露（投影可靠性 cos2 低于门槛的品牌/属性单独列出，位置仅供参考）；感知空白与动作建议（写明前提：感知空白不等于机会保证） | 引擎产出（见调用） | | 跟踪口径设计 | 新品/新属性走只投影不参与拟合的补充元素机制，挂图不扰动既有坐标结构；期际可比条件（属性清单、排除口径、路由与角色设定锁死）写明 | 引擎产出（见调用） |

使用示例与输出样例（合成数据，演示交付形态）

下例全部品牌、属性与数字为合成示例，只为展示交付形态与口径；真实交付中每个数字必须来自用户自己的数据或引擎产出。

场景：虚构即饮茶市场，问卷「每个品牌符合哪些属性（可多选）」，导出「品牌，属性，勾选人次」列联汇总：5 品牌 × 8 属性；目标=上市前找差异化空白。

  • 体检（对话内）：表型=列联汇总 ✔ → 非负、口径统一按勾选人次 → 「无糖」总提及 41 人次低于门槛，挂补充列 → 行=品牌 5 个、列=主拟合属性 7 个+补充 1 个
  • 路由（对话内）：恰好两列结构、无数值列、无题组分组 → 对应分析
  • 引擎调用：scenario="zvex-perceptual-map"，situation 放上述体检与路由结论的浓缩（报文见 references/api.md）

输出样例（节选，合成数字）：

  • 维度 1（解释率 52.3%）：正端贡献属性「提神功能（31%）、专业工艺（24%）」，负端「解渴日常（28%）」→ 两极命名：功能专业 vs 日常解渴
  • 维度 2（解释率 26.8%）：正端「国潮包装、年轻社交」，负端「长辈熟识、经典配方」→ 潮流感 vs 经典感；累计解释率 79.1%
  • 品牌落位：「甲品牌与丙品牌落点几乎重合——被同一组属性（解渴日常+经典）感知，竞争簇（图中以椭圆标示）；乙品牌独占『功能专业』端；自家新品牌丁为补充元素，cos2=0.34 低于门槛，位置仅供参考不进主解读。」
  • 感知空白（示例话术）：「『功能专业×潮流感』象限当前无主品牌落位——这是感知空白，不是机会保证；要不要占先看品类容量与自身供给，再小步验证传播主张。」
  • 跟踪口径：「下一期新品牌走只投影不重建；属性清单与排除口径锁死，期际解释率与坐标才可比。」

能力边界与限制

  • 只画感知结构不做因果：回答「谁被感知成什么样、谁和谁挤在一起、空白在哪」，不回答「为什么被这样感知」；不预测市场份额；不把感知接近说成因果
  • 只吃共现结构数据：列联汇总或受访者级分类作答；评分均值表、NPS 汇总、含负值或已标准化的表一律退回并给还原路径；截图/图片（未转成文本表格前）退回
  • 小样本只给方向：品牌×属性格子提及量过稀时结构不稳，明说「只能给方向性观察」；极低提及元素建议挂补充列，只能给标注了可靠性限制的结论
  • 空白不是机会保证：感知空白要结合品类容量、供给可行性与渠道现实再谈动作，怎么拍板由品牌方决定
  • 不做：定价弹性测算、销量预测、媒介投放计划；不操作任何投放后台
  • 隐私红线：受访者级明细先脱敏概括再进调用参数；个人信息禁止写进任何参数

常见问题与反模式（FAQ）

高频问答：

  • 只有百分比汇总表，没有原始作答行，能做吗？ 能——列联口径（品牌×属性）一致即可，计数与占比选一种并全程统一；但行列质量由边缘提及量决定，极低提及的品牌/属性会缩在原点附近，如实披露。
  • 维度 1、维度 2 是什么意思？ 统计维度本身没有业务含义——按贡献度最高的属性做两极命名（如「功能专业 vs 日常解渴」）才算交付；命名与业务直觉对不上时，先回头检查路由与排除口径，不硬拗。
  • 为什么我们品牌画出来的位置不对？ 先看投影可靠性（cos2）：低于门槛的品牌图上位置不可信，报告会单独披露；别按不可靠落点讲故事。
  • 两个品牌挤在一起说明什么？ 竞争簇——被消费者用同一组属性感知，差异化空间小；这是描述，不是因果，也不是谁抄谁。
  • 空白象限是不是就是市场机会？ 是感知空白，不是机会保证；要不要占，先结合品类容量、供给可行性与渠道现实，再小步验证。
  • 评分题和人群标签能一起放进图里吗？ 能——数值+分类混合走混合数据路由，两类变量影响力已做平衡；题目按题组分块走多表路由，还能回答「哪个题组主导整体结构」。
  • 多分类数据不做校正会怎样？ 指示矩阵会系统性低估惯量，报出来的方差解释率是失真的——本技能默认做特征值校正，校正方式写进口径声明。
  • 新品上市后要整张重画吗？ 不必——新品牌作为补充元素只投影不参与拟合，挂到既有图上；跟踪期属性清单与排除口径锁死，期际才可比。
  • 换个说法再问一次会重新处理吗？ 不会——判重按问题身份；补充材料说明不产生新订单；不确定状态就用相同参数传查单动作查询。
  • 付了款怎么还没收到报告？ 核销有短暂延迟：等 1 分钟回「付好了」，用相同参数重调一次；不反复重试、不换参数（换参数=新订单）。

反模式（命中即返工）：

  • 拿负值或标准化表硬当列联表；什么数据都上同一种方法不路由
  • 多分类数据跳过特征值校正就报方差解释率；汇总计数与占比混用
  • 维度只报编号不命名；贡献度 Top 属性与命名两张皮；命名与贡献对不上还硬拗
  • cos2 低的点照样解读位置不披露；竞争簇不标示；把感知接近说成因果；空白象限直接当机会拍板
  • 出订单后换参数重试；把核销延迟当失败反复刷单；报告贴原始统计输出不转译
  • 套模板——换一份不同品牌结构的表，结论不变

护栏

  • 路由不过不动手：数据形态没有判定、方法没有路由依据就不进深度交付；负值表、均值表、口径混用一律退回
  • 默认特征值校正：多对应分析不校正不报方差解释率；校正方式必须写进口径声明
  • 命名必须挂钩贡献度：维度两极命名来自贡献 Top 属性；命名与贡献对不上先修路由与口径，不硬拗标签
  • 可靠性披露是强制项：投影可靠性低于门槛的品牌/属性单独列出；不把不可靠落点讲成战略洞察
  • 感知结构不冒充因果与机会：竞争簇是描述；空白象限的建议必须带前提；每个数字可溯源到用户数据，缺数据先明说

调用

完整感知定位图报告与跟踪口径设计走 zvex 类目引擎·营销增长 MCP（Streamable HTTP 三步会话流：initialize 拿 mcp-session-id → notifications/initialized → tools/call）：

  1. 首次调用（payment_proof 留空）：

    {"jsonrpc":"2.0","id":2,"method":"tools/call","params":{
  "name":"analyze_consult",
  "arguments":{"scenario":"zvex-perceptual-map","situation":"<体检与路由结论浓缩：表型判定+非负与口径核对+方法路由依据+行列角色设定+排除口径+业务目标>","goal":"<以 consult_info 探针返回的当前列表为准>","mode":"standard","known_facts":"<体检段确认的口径、品牌数与属性数、路由结论、方向性发现>","goal_detail":"","payment_proof":""}}}

    必须传 scenario="zvex-perceptual-map"（技能身份绑定，漏传拿到的是通用营销分析包）；goal 以 consult_info 探针返回的当前列表为准，也接受中文。

  2. 返回账单：结果内 code=Payment-Needed，含 out_trade_no、amount、pay_url（收银台直链）与结果概要。把 pay_url 原样发给用户，点开可选支付宝（手机自动拉起）或微信扫码支付；完成后引导用户等 1 分钟左右回一句「付好了」。防反推：结果概要只含报告板块与条数，转述时不要展开细节（完整口径见 references/api.md）。

  3. 支付后交付：用户回复「付好了」后系统自动查单交付完整结果，无需任何凭证；确需改参数先征得用户同意再重新发起。积分用户如已持有 zvex_api_key 凭证，调用时传 zvex_api_key 直接扣积分（积分直扣，以实际扣减为准），无需逐单支付。

完整会话流、参数表、两栏字段表、幂等语义与错误处理见 references/api.md。

输出纪律

  • 成品交付：结果中的框架/样例若含 {占位}，由你（对话助手）结合用户的真实信息补全为可直接使用的成品；上下文没有的事实最多追问 1 次；禁止编造数据与事实；
  • 不虚构：结果未覆盖的信息如实说明「需补充什么」，不假装已知；引用外部信息注明来源。

交付与计费纪律

  • 交付状态机：首次调用返回账单（402，内含 pay_url 收银台直链，支付宝/微信均可付）→ 用户完成后回复「付好了」→ 系统自动查单交付完整结果，无需任何凭证，不会重复扣费；
  • 判重语义：同一问题重复查询不重复扣费——判重按问题身份（situation+goal+mode+scenario，即相同情境+目标+模式+场景）；补充已知信息或修改目标说明不会产生新账单，交付始终使用最新提供的信息；
  • 查单：不确定订单状态时，用相同参数调用并传 action=check_order（不产生账单）即可查询，不要靠更换参数试探；
  • 换参数=新问题=新账单：出账单后不要更换参数重试。

证据呈现纪律

  • 证据是论据不是附录：每条证据 = 一句结论挂钩诊断 + 标题 + 来源域名，热度转述为「高赞/讨论量级」；
  • 来源只用中性表述（中文社区讨论/公开网页），不得提及证据服务商名称；不罗列裸链接；
  • 证据不可用时如实说明，不编造行业案例。