cameronalexander720/overseas-ad-attribution-link-skill

Overseas Ad Attribution Link Skill

Operating Mode

Use this skill for two output types:

1. Technical solution design for overseas ad attribution link capabilities.
2. Q&A and troubleshooting for attribution, parameters, SDK timing, PushAPI, landing pages, deep links, event callbacks, reporting controls, and post-install routing behavior.

Identify the mode first. Use solution-design mode when the user asks for a technical solution, integration plan, product/technical review, feature design, or architecture. Use Q&A mode when the user asks why a chain behaves a certain way, how to judge a source, where a parameter comes from, how a link stage works, or how to troubleshoot a metric or behavior symptom.

Required Reference Loading

Load only the references needed for the request:

• For technical solution or functional architecture: read references/technical-solution-template.md.
• For attribution rules, data-source priority, interface timing, parameter mapping, or event callbacks: read references/attribution-knowledge.md.
• For usage questions, diagnosis, or explanation: read references/qa-playbook.md.

Do not load or cite customer-specific source documents unless the user explicitly provides them for the current task.

Solution-Design Workflow

When drafting an overseas ad attribution link solution:

1. Clarify the scenario: deep link, landing page, SDK attribution, PushAPI, Google Install Referrer, or mixed chain.
2. Identify the business goal: attribution completion, ad hierarchy backfill, event callback, post-install routing to promoted content, model-learning signal, reporting control, or metric reconciliation.
3. Define actors and modules: media platform, ad-link generator, landing-page smart script, app client, SDK/MMP, backend attribution service, reporting service, admin configuration, and data warehouse.
4. Specify data sources and priority. Document each source's timing, reliability, matching key, fallback behavior, and allowed use.
5. Specify client timing: cold start, first install open, privacy consent, SDK callback timing, fallback timeout, short polling, hot start, and session-level limits.
6. Specify backend behavior: matching, deduplication, spread mapping, ad hierarchy backfill, event eligibility, and callback routing.
7. Specify user-facing behavior: auto-route, route prompt, route suppression when the user is already consuming content, or delay until attribution result arrives.
8. Specify validation: cases by source/channel, parameter examples, expected logs, event callbacks, metric checks, gray release, and rollback switches.

Use references/technical-solution-template.md as the structure. Remove sections that are irrelevant to a narrow request.

Q&A Workflow

When answering usage questions:

1. Restate the observed symptom or decision point.
2. Name the relevant chain stage: ad click, landing page, install, first open, SDK callback, pre-attribution, post-attribution, ad-info request, event callback, or analytics reconciliation.
3. Map it to known rules in references/attribution-knowledge.md.
4. Explain the likely cause with source priority and timing, especially when PushAPI, Google Install Referrer, or SDK data arrives late.
5. Give a verification checklist: logs, fields, request timing, user state, spread/ad hierarchy fields, event eligibility, and reporting switch.
6. Separate confirmed facts from assumptions. If the current project has its own rules, ask the user for the relevant rule or document excerpt before overriding the generic pattern.

Domain Guardrails

• Distinguish attribution completion from post-install routing/playback success; a user can be attributed but not routed to promoted content.
• Distinguish pre-attribution and post-attribution. Pre-attribution affects immediate app behavior; post-attribution can complete attribution later but may require polling or routing compensation.
• Treat Google Install Referrer as first-install-open oriented. Do not assume it updates for every new ad click after install.
• Prefer explicit source-priority rules over "latest field wins" unless the user states a project-specific rule.
• When discussing event callback, separate media event mapping, eligibility rules, deduplication, and reporting switches.
• When a metric issue appears, inspect both attribution timing and app experience before concluding the attribution logic is wrong.

Sensitive-Context Guardrails

• Do not include company names, project names, document names, historical dates, personal names, local file paths, tokens, URLs, package names, campaign names, or raw log examples in generated reusable guidance.
• Public media/platform names such as Facebook, TikTok, Snapchat, and Google may be retained when relevant to solution design or troubleshooting.
• Internal company names, project names, document titles, campaign names, package names, and raw account identifiers must be removed or generalized.
• Use generic categories such as "media SDK", "MMP SDK", "social media channel", "ad network", "landing-page log", or "install-source API" when the source is internal, customer-specific, or not necessary to the answer.
• Use relative timing such as "initial request", "fallback timeout", and "short polling window"; avoid historical dates unless the user supplies dates for the current deliverable.