# Persona & Role
You are a **Principal Data Architect** and **Lead SaaS Product Manager** specializing in multi-channel e-commerce integrations, unified analytics engines, and canonical data modeling.

---

# Context & Background
**BoothPulse** is a specialized SaaS backend and analytics platform designed for independent artists, festival vendors, and pop-up creators who sell across both physical in-person booths (POS) and online channels. 

To power BoothPulse’s unified analytics engine, the system must ingest, normalize, and synthesize historical operational data from 8 external target platforms:
1. **Shopify**
2. **Square**
3. **Stripe**
4. **Clover**
5. **PayPal** (Commerce Platform / REST APIs)
6. **WooCommerce**
7. **Wix Studio**
8. **Squarespace**

---

# Objective
Design a comprehensive **High-Level Analytics & Data Normalization Specification** (Product Design Document). The goal is to define an abstract canonical data model based on universal or near-universal fields available across all 8 target platforms, and outline high-value historical analytics features that provide immediate operational insights to BoothPulse users.

---

# Core Domains to Analyze
Your analysis must cover four core operational domains:
1. **Orders:** Line items, sales volume, discounts, taxes, fulfillments, channel source, order status.
2. **Inventory & Catalog:** Products, variants, SKUs, stock counts, adjustments, multi-location/booth tracking.
3. **Customers:** Profiles, contact identifiers, purchase frequency, order history, customer lifetime value (LTV).
4. **Payments & Payouts:** Payment methods, processing fees, net processing amounts, deposit/payout schedules.

---

# Detailed Task Directives

### Task 1: Abstract Canonical Schema Definition
Create an abstract, vendor-agnostic canonical schema for each of the four core domains. 
* Focus exclusively on **universal or near-universal abstract fields** present across the target providers.
* Use abstract, normalized naming conventions (e.g., `gross_transaction_amount`, `discount_total`, `customer_unique_id`, `payout_batch_date`) rather than provider-specific API field names.
* Present this mapping in Markdown tables containing: **Abstract Field Name**, **Data Type**, **Domain Category**, and **Universal Availability (High / Medium)**.

### Task 2: Historical Analytics Suite & Feature Design
Identify and specify actionable historical analytics features that can be computed using *only* the canonical fields defined in Task 1. Categorize these analytics into:
* **Sales & Revenue Performance:** Gross vs. Net revenue, channel attribution (In-Person POS vs. Online E-Commerce), average order value (AOV), peak sales periods (booth rush hours vs. online traffic).
* **Inventory & Catalog Insights:** Top-performing SKUs by margin and volume, sell-through rates, inventory velocity, stockout forecasting, dead stock identification.
* **Customer Behavior Analytics:** Repeat vs. new customer ratios, purchase frequency, customer retention across events/channels, LTV segmentation.
* **Financial & Payout Reconciliation:** Total processing fees paid across providers, net cash flow trends, payout deposit schedules vs. real-time sales, tax liabilities.

### Task 3: Analytics Specification Breakdown
For each proposed analytics feature in Task 2, provide:
1. **Feature Name & Description**
2. **Target User Insight:** (What specific business question does this answer for a pop-up vendor or artist?)
3. **Required Canonical Input Fields**
4. **Mathematical/Logical Calculation Logic**

### Task 4: Data Gap & Fallback Analysis
Identify potential edge cases or missing fields across certain lower-tier REST APIs (e.g., missing payout fee breakdowns or incomplete customer contact details on POS checkouts). Provide recommended fallback strategies (e.g., manual fee estimation, anonymous guest grouping).

---

# Constraints & Guidelines
* **Vendor Agnostic:** Do not hardcode provider-specific JSON response keys. Keep field representations abstract and functional.
* **Historical Focus:** Limit features to insights derived from historical operational data.
* **Actionable for Micro-Merchants:** Focus on insights that help independent creators optimize event stock, understand true margins after fees, and evaluate channel profitability.

---

# Expected Output Format
Structure your response as a formal **Product Design Document** using clean Markdown syntax:
- `## Executive Summary`
- `## Abstract Canonical Data Schema` (Tables broken down by Domain)
- `## Historical Analytics Feature Specifications` (Grouped by Category)
- `## Data Gap Analysis & Fallback Strategies`