Fusionaly-oss fusionaly
Use when user asks about website analytics, traffic, visitors, page views, referrers, or mentions "fusionaly". Queries Fusionaly analytics via SQL API.
git clone https://github.com/karloscodes/fusionaly-oss
T=$(mktemp -d) && git clone --depth=1 https://github.com/karloscodes/fusionaly-oss "$T" && mkdir -p ~/.claude/skills && cp -r "$T/.claude/skills/fusionaly" ~/.claude/skills/karloscodes-fusionaly-oss-fusionaly && rm -rf "$T"
.claude/skills/fusionaly/SKILL.md- makes HTTP requests (curl)
Fusionaly Agent API
Query your Fusionaly analytics data using SQL.
Your role: The user will ask questions in plain English (e.g., "What were my top pages last week?" or "How many visitors did I get from Google?"). You translate these questions into SQL queries, execute them via the API, and present the results in the most readable format possible (tables, summaries, bullet points, or charts as appropriate).
Environment Variables
Requires these environment variables to be set:
- Your Fusionaly instance URL (e.g.,FUSIONALY_HOST
)https://analytics.example.com
- Your Agent API key from Administration → AgentsFUSIONALY_API_KEY
Workflow
Step 1: Fetch and Interpret the Schema
curl -s -H "Authorization: Bearer $FUSIONALY_API_KEY" "$FUSIONALY_HOST/z/api/v1/schema"
The response contains:
: Raw SQLite CREATE TABLE statements showing all tables and columnsschema
: Domain-specific explanations of what each table/column meansconcepts
How to use the schema:
- Parse the CREATE TABLE statements to learn exact table names and column names
- Use the
section to understand what each column representsconcepts - Build your SQL queries using only the columns that exist in the schema
- Always use the exact column names as shown (case-sensitive)
Step 2: Execute SQL Queries
curl -s -X POST "$FUSIONALY_HOST/z/api/v1/sql" \ -H "Authorization: Bearer $FUSIONALY_API_KEY" \ -H "Content-Type: application/json" \ -d '{"sql": "SELECT ...", "website_id": 1}'
Build your SELECT queries based on:
- Table names from the schema (e.g.,
,events
,sessions
)visitors - Column names exactly as defined in CREATE TABLE statements
- Relationships implied by foreign keys (e.g.,
,website_id
)visitor_id
Error Handling
Be persistent. If a query fails, analyze the error and retry with corrections. Try up to 3 times before giving up.
Common errors and fixes:
→ Re-check schema for correct table nameno such table: X
→ Re-check schema for correct column name (case-sensitive)no such column: X
→ Remove any non-SELECT statementsonly SELECT queries allowed
→ Removecomments not allowed
or--
from query/* */
→ Use only one SELECT statementmultiple statements not allowed
→ Remove blocked keywords, use only SELECT/WITHdangerous operation not allowed
Always bias toward solving the problem. Don't give up on first error - read the message, fix the query, retry.
Constraints
- Read-only: Only SELECT/WITH queries are allowed
- Rate limited: 30 requests per minute
- Query timeout: 5 seconds
- No comments: SQL comments (
or--
) are not allowed/**/
Domain Concepts
Visitors vs Sessions
- Visitor: A unique user identified by a hash signature (no cookies, privacy-first)
- Session: A browsing session, expires after 30 minutes of inactivity
Events
- Pageview: A page visit with path, referrer, UTM parameters
- Custom Event: User-defined events with optional properties
Time-based Analysis
- Data is typically queried by date ranges
- Use
for daily aggregationsDATE(timestamp) - Timestamps are stored in UTC
Website Context
- All queries should filter by
website_id - Pass
in the request body alongside the SQL querywebsite_id