# Privacy & Compliance
Source: https://docs.cryptique.io/admin/privacy-and-compliance
Data privacy settings, compliance, and security practices
## Overview
Cryptique is designed with privacy in mind. This guide covers data handling practices, compliance features, and how to configure privacy settings for your team.
## Data Collection
### What Cryptique Collects
**Automatically collected:**
* Page views and navigation
* User interactions (clicks, scrolls, form submissions)
* Device and browser information
* Geographic location (approximate, from IP)
* Session data
* Wallet connections (when detected)
* On-chain transactions (for tracked contracts)
**Not collected:**
* Form field values (only metadata)
* Passwords or sensitive credentials
* Credit card numbers
* Personal health information
* Full IP addresses (not stored)
### Default Properties
All automatically captured properties are listed in [Default Properties](/data-in/default-properties).
```
What's captured:
├── country: "US" (approximate)
├── city: "San Francisco" (approximate)
├── device_type: "desktop"
├── browser_name: "Chrome"
└── ...
What's NOT captured:
├── IP address (used for geo, then discarded)
├── form_values (only form metadata)
└── sensitive_data
```
## Privacy by Design
### IP Address Handling
Cryptique uses IP addresses for geolocation but does not store them:
```
Request comes in with IP: 192.168.1.1
├── Geolocation lookup → "San Francisco, US"
├── IP discarded (not stored)
└── Event stored with location only
```
### Data Minimization
We collect only what's necessary:
* Element text is truncated (not full page content)
* Copied text is limited to 100 characters
* Form values are excluded (only form metadata)
* Input changes track field names, not values
### Pseudonymization
User identifiers are pseudonymous by default:
```
Anonymous user: anon_abc123xyz
Identified user: user_provided_id (your choice)
```
You control what identifying information to associate with users.
Wallet addresses follow the same principle: they are stored as pseudonymous identifiers and are only associated with a user profile when the End-User explicitly connects their wallet. See "Wallet Address Handling" below.
### Wallet Address Handling
Wallet addresses (e.g. `0x1234...abcd`) are stored as-is and are **pseudonymous by nature** — they identify a wallet, not a named individual, unless the user explicitly links additional identity information (such as an email address via `Cryptique.identify()`).
Important considerations:
* Blockchain transaction data is **publicly available**. Anyone can look up a wallet's history on a block explorer. Cryptique aggregates this public data; it does not expose anything that isn't already on-chain.
* Cryptique does **not** use heuristics or clustering to deanonymize wallets. A wallet address is only linked to a user profile when the End-User explicitly connects their wallet.
* Under GDPR, wallet addresses may be considered personal data if they can be linked to an identified individual. If your End-Users are in the EEA, ensure your privacy policy discloses wallet address collection and that you have a lawful basis for processing it.
* Wallet addresses are subject to the same retention periods as other profile data (default 24 months, configurable).
## Consent Management
### Consent-Based Tracking
Cryptique can be loaded conditionally based on user consent:
```javascript theme={null}
// Only load after consent
if (userHasConsented()) {
var script = document.createElement('script');
script.src = 'https://cdn.cryptique.io/scripts/analytics/1.0.1/cryptique.script.min.js';
script.setAttribute('site-id', 'YOUR_SITE_ID');
document.head.appendChild(script);
}
```
### Integration with CMPs
Works with Consent Management Platforms:
**OneTrust:**
```javascript theme={null}
OneTrust.OnConsentChanged(function(e) {
if (OnetrustActiveGroups.includes('C0002')) {
// Performance cookies consented - load Cryptique
loadCryptique();
}
});
```
**Cookiebot:**
```javascript theme={null}
window.addEventListener('CookiebotOnAccept', function(e) {
if (Cookiebot.consent.statistics) {
loadCryptique();
}
});
```
## Data Retention
### Retention Periods
Configure how long data is retained:
| Data Type | Default Retention | Configurable |
| ------------- | ----------------- | ------------ |
| Events | 24 months | Yes |
| User profiles | 24 months | Yes |
| Sessions | 24 months | Yes |
| Transactions | 24 months | Yes |
### Configuring Retention
1. Go to **Settings** → **Privacy**
2. Set retention period for each data type
3. Data older than retention period is automatically deleted
Shorter retention periods reduce storage but limit historical analysis.
## Data Access & Export
### Who Can Access Data
| Role | Data Access |
| ---------- | -------------------------- |
| Super User | Full access |
| Admin | Full access |
| User | Full access (configurable) |
All data access is logged in the audit trail.
### User Data Requests
For GDPR/CCPA data subject requests:
**Data Export:**
1. Search for user by email, wallet, or ID
2. View user profile
3. Export user data as JSON
**Data Deletion:**
1. Search for user
2. Click **Delete Profile**
3. Confirm deletion
User deletion is permanent and cannot be undone.
## Audit Logging
All significant actions are logged:
```
Audit Log:
├── Feb 15, 2:30 PM │ admin@example.com │ Viewed user profile: user_123
├── Feb 15, 2:15 PM │ admin@example.com │ Exported user data: user_456
├── Feb 15, 1:00 PM │ owner@example.com │ Changed retention period to 6 months
├── Feb 14, 4:45 PM │ admin@example.com │ Deleted user profile: user_789
└── ...
```
**Logged actions:**
* User profile views
* Data exports
* Configuration changes
* User deletions
* Team member changes
* Site/contract modifications
## Security
### Data Encryption
| State | Encryption |
| ---------- | ---------- |
| In transit | TLS 1.3 |
| At rest | AES-256 |
### Infrastructure
* Data centers in secure, SOC 2 compliant facilities
* Regular security audits
* Penetration testing
* Incident response procedures
### Access Controls
* Role-based access (Super User, Admin, User)
* All access logged
* Session timeouts
* Secure authentication
## Data Storage & Infrastructure
### Where your data is stored
All Cryptique data is stored and processed on **Google Cloud Platform (GCP)** in the **us-central1** region (Iowa, United States).
| Layer | Provider | Region |
| ------------------------ | --------------------- | ---------------- |
| Application hosting | Google Cloud Platform | us-central1 (US) |
| Database & event storage | Google Cloud Platform | us-central1 (US) |
| CDN & DDoS protection | Cloudflare | Global edge |
Enterprise customers may request EU-only data residency as part of a custom agreement. Contact [privacy@cryptique.io](mailto:privacy@cryptique.io) to discuss data residency requirements.
### Security certifications
| Certification | Status |
| ------------- | -------------- |
| GDPR | ✅ Compliant |
| CCPA / CPRA | ✅ Compliant |
| SOC 2 Type II | 🔄 In progress |
| ISO 27001 | 🔄 In progress |
Cryptique's infrastructure runs on Google Cloud Platform, which holds SOC 2 Type II and ISO 27001 certifications at the infrastructure level. Cryptique's own SOC 2 Type II audit is currently in progress. When completed, the report will be available to enterprise customers under NDA.
## Compliance
### GDPR
Cryptique supports GDPR compliance:
✅ **Data minimization**: Collect only necessary data
✅ **Purpose limitation**: Analytics purpose clearly defined
✅ **Storage limitation**: Configurable retention periods
✅ **Right to access**: Export user data
✅ **Right to erasure**: Delete user profiles
✅ **Data portability**: JSON export format
**Your responsibilities:**
* Obtain proper consent before tracking
* Update privacy policy to mention Cryptique
* Honor data subject requests
### CCPA
For California Consumer Privacy Act:
✅ **Right to know**: Access user data via search
✅ **Right to delete**: Delete user profiles
✅ **Right to opt-out**: Honor user preference (e.g. do not load SDK when user opts out)
### Cookie Usage
Cryptique uses first-party cookies for:
| Cookie | Purpose | Duration |
| ---------------- | ------------------- | ---------- |
| `cq_distinct_id` | User identification | 1 year |
| `cq_session_id` | Session tracking | 30 minutes |
No third-party cookies are used.
## Privacy Settings
### Configurable Options
Access via **Settings** → **Privacy**:
| Setting | Description |
| --------------- | --------------------------------- |
| Data retention | How long to keep data |
| IP geolocation | Enable/disable location tracking |
| Auto-events | Which automatic events to capture |
| Sensitive paths | Paths to exclude from tracking |
### Exclude Sensitive Pages
Exclude pages from tracking:
```javascript theme={null}
script.setAttribute('auto-events-disabled-paths', '/account,/settings,/admin');
```
Or configure in dashboard:
```
Excluded Paths:
├── /account/*
├── /settings/*
├── /admin/*
└── /checkout/*
```
### Disable Specific Events
Disable events that might capture sensitive data:
```javascript theme={null}
script.setAttribute('auto-events-disabled-events', 'text_selection,copy_action');
```
## Data Processing Agreement
For customers who require a formal Data Processing Agreement (DPA) — including those operating under GDPR — Cryptique provides:
| Document | Available |
| ---------------------------------------- | ----------------------- |
| Data Processing Agreement (DPA) | ✅ On request |
| EU Standard Contractual Clauses (SCCs) | ✅ On request |
| UK International Data Transfer Addendum | ✅ On request |
| HIPAA Business Associate Agreement (BAA) | On request (enterprise) |
To request any of these documents, email [privacy@cryptique.io](mailto:privacy@cryptique.io) with the subject line **"DPA Request"**. We aim to respond within 2 business days.
## Best Practices
### Before Going Live
1. ✅ Review what data you're collecting
2. ✅ Update your privacy policy
3. ✅ Implement consent if required
4. ✅ Configure data retention
5. ✅ Exclude sensitive paths
6. ✅ Test that opt-out is honored (e.g. SDK not loaded when user opts out)
### Ongoing
* Regularly review data collection
* Honor data subject requests promptly
* Keep team access up to date
* Monitor audit logs
### Privacy Policy Template
Include in your privacy policy:
```
Analytics
We use Cryptique for product analytics. Cryptique collects:
- Pages visited and interactions
- Device and browser information
- Approximate location (country/city)
- Wallet addresses (if you connect a wallet)
This data helps us improve our product. We do not sell your data.
You can opt out of analytics by disabling or not loading the analytics script.
For more information, see Cryptique's privacy policy at
https://cryptique.io/privacy
```
## Troubleshooting
1. Search for user by email, wallet, or ID
2. Open user profile
3. Click **Delete Profile**
4. Confirm deletion
5. Notify user of completion
1. Search for user
2. Open user profile
3. Click **Export** → **JSON**
4. Provide exported file to user
Use conditional loading - only load Cryptique after user grants consent. See "Consent-Based Tracking" section above.
## Next Steps
Configure team access
See what's collected
# Sites & Contracts
Source: https://docs.cryptique.io/admin/sites-and-contracts
Configure tracked websites and smart contracts
## Overview
Cryptique tracks data from two sources: websites (sites) and blockchain smart contracts. This guide covers how to configure and manage both.
## Sites
Sites are the websites or web applications you want to track with Cryptique.
### Adding a Site
Navigate to **Settings** → **Sites**
Click **Add Site**
* **Name**: Human-readable name (e.g., "Production App")
* **Domain**: Your website domain (e.g., `app.example.com`)
After creation, you'll receive a **Site ID** to use in your tracking code
### Site Configuration
```
Site: Production App
├── Site ID: prod-app-12345
├── Domain: app.example.com
├── Status: Active
├── Created: Jan 1, 2024
└── Last Event: 2 minutes ago
```
### Multiple Sites
One team can have multiple sites:
```
Team Sites:
├── Production (app.example.com)
│ └── Site ID: prod-app-12345
├── Staging (staging.example.com)
│ └── Site ID: staging-app-67890
└── Marketing (www.example.com)
└── Site ID: marketing-site-abcde
```
**Use cases for multiple sites:**
* Separate production and staging
* Track multiple products
* Different domains for different regions
### Domain Whitelist
For security, Cryptique only accepts events from whitelisted domains:
```
Allowed Domains for prod-app-12345:
├── app.example.com ✓
├── www.example.com ✓
└── *.example.com (wildcard) ✓
```
Add domains that should be allowed to send events with this Site ID.
### Site Settings
| Setting | Description |
| ------------------- | -------------------------------- |
| **Auto-enhance** | Enable/disable wallet enrichment |
| **Auto-events** | Default auto-event configuration |
| **Allowed domains** | Domains that can send events |
| **Data retention** | How long to keep event data |
## Smart Contracts
Smart contracts let you track on-chain transactions and link them to user behavior.
### Adding a Contract
Navigate to **Settings** → **Contracts**
Click **Add Contract**
* **Name**: Human-readable name (e.g., "Swap Router")
* **Address**: Contract address (e.g., `0x1234...abcd`)
* **Chain**: Select blockchain network
* **ABI** (optional): Contract ABI for method decoding
Contract transactions will start appearing in your data
### Contract Configuration
```
Contract: Swap Router
├── Address: 0x1234567890abcdef...
├── Chain: Ethereum
├── Status: Active
├── ABI: Uploaded ✓
├── Methods Tracked: swapExactTokensForTokens, swapTokensForExactTokens
└── Last Transaction: 5 minutes ago
```
### Supported Chains
Cryptique supports 35 chains for smart contract tracking:
* Ethereum
* Polygon
* Arbitrum
* Optimism
* Base
* Avalanche
* BNB Chain
* Fantom
* Gnosis
* And more...
* Arbitrum One
* Arbitrum Nova
* Optimism
* Base
* zkSync Era
* Polygon zkEVM
* Linea
* Scroll
* And more...
See [Chain Support](/integrations/overview) for the complete list.
### Contract Naming
Use consistent names across contracts for cross-protocol analysis:
```
✅ Good naming:
├── "Swap Router" (on Ethereum)
├── "Swap Router" (on Polygon)
├── "Swap Router" (on Arbitrum)
└── All appear as "Swap Router" in reports
❌ Poor naming:
├── "Uniswap V3 Router ETH"
├── "Polygon Swap"
├── "Arb Router Contract"
└── Appears as separate entities
```
Consistent naming lets you:
* Filter by contract name across all chains
* Compare performance across chains
* Create unified reports
### ABI Upload
Upload the contract ABI to decode method names and parameters:
**Without ABI:**
```
Transaction:
├── Method: 0x38ed1739
├── Input: 0x00000...
└── (Raw data only)
```
**With ABI:**
```
Transaction:
├── Method: swapExactTokensForTokens
├── Parameters:
│ ├── amountIn: 1000000000000000000
│ ├── amountOutMin: 950000000
│ ├── path: [0xETH..., 0xUSDC...]
│ └── deadline: 1707994800
└── (Human-readable)
```
### Multi-Chain Contracts
For contracts deployed on multiple chains, add each deployment:
```
Swap Router (Multi-chain):
├── Ethereum: 0x1234...
├── Polygon: 0x5678...
├── Arbitrum: 0x9abc...
└── Base: 0xdef0...
```
Use the same **Name** for all deployments to enable cross-chain analysis.
## Data Flow
### Site → Contract Attribution
When a user:
1. Visits your site (tracked via Site ID)
2. Connects their wallet (captured via SDK)
3. Makes a transaction (tracked via Contract)
Cryptique links all three via the wallet address, creating complete attribution.
```
User Journey:
├── [Site] page_view (landing)
├── [Site] wallet_connect (0x1234...)
├── [Site] swap_initiated
└── [Contract] swapExactTokensForTokens (0x1234...)
→ Full attribution: Landing → Wallet → Transaction
```
### Cross-Site Tracking
If a user visits multiple sites with the same wallet:
```
User: 0x1234...
├── Site A: 15 events
├── Site B: 8 events
└── Contract: 5 transactions
→ Unified user profile across sites
```
## Managing Sites & Contracts
### Edit Configuration
1. Go to **Settings** → **Sites** or **Contracts**
2. Click the item to edit
3. Modify settings
4. Save changes
### Archive vs Delete
**Archive**: Stops tracking new data but preserves historical data
**Delete**: Removes configuration (historical data retained per retention policy)
Deleting a site removes the Site ID. Any tracking code using that ID will stop working.
### Status Monitoring
Check health of your sites and contracts:
```
Sites Status:
├── prod-app-12345: ✅ Active (1,234 events/hour)
├── staging-67890: ⚠️ Low activity (2 events/hour)
└── old-site-xyz: ❌ No events (30+ days)
Contracts Status:
├── Swap Router (ETH): ✅ Active (45 txns/hour)
├── Swap Router (POLY): ✅ Active (120 txns/hour)
└── Old Contract: ❌ No transactions (60+ days)
```
## Best Practices
### Site Organization
```
✅ Recommended:
├── One site per environment (prod, staging, dev)
├── Separate sites for distinct products
├── Consistent naming convention
❌ Avoid:
├── One site for everything (hard to filter)
├── Duplicate sites for same domain
├── Cryptic Site IDs in production code
```
### Contract Organization
```
✅ Recommended:
├── Consistent names across chains
├── Upload ABIs for better data
├── Group related contracts logically
├── Archive unused contracts
❌ Avoid:
├── Different names for same contract on different chains
├── Tracking contracts you don't own (unless needed)
├── Leaving stale contracts active
```
### Security
* Keep Site IDs confidential (treat like API keys)
* Use domain whitelisting
* Regularly audit active sites and contracts
* Remove unused configurations
## Troubleshooting
1. Verify Site ID in tracking code
2. Check domain is whitelisted
3. Ensure SDK is loading correctly
4. Check browser console for errors
1. Verify contract address is correct
2. Check chain selection
3. Ensure contract is active on-chain
4. Wait a few minutes for indexing
Upload the contract ABI to decode method names and parameters.
Ensure contracts use the same **Name** across all chains for unified reporting.
## Next Steps
Deep dive into contract tracking
Enrich user profiles with on-chain data
# Team Management
Source: https://docs.cryptique.io/admin/team-management
Manage team members, roles, and permissions
## Overview
Cryptique uses a role-based access system to manage team permissions. This guide covers user roles, invitations, and team administration.
## User Roles
Cryptique has three user roles with different permission levels:
### Super User (Team Owner)
The Super User is the team owner with full administrative control:
| Permission | Access |
| ------------------- | ----------------------- |
| Billing management | ✅ Full access |
| Team deletion | ✅ Can delete team |
| Admin capabilities | ✅ All admin permissions |
| Invite users | ✅ Yes |
| Manage integrations | ✅ Yes |
| View all data | ✅ Yes |
The Super User role is fixed and cannot be transferred. The person who created the team is automatically the Super User.
### Admin
Admins can manage team settings and users but cannot access billing:
| Permission | Access |
| ------------------------ | ------------------------- |
| Billing management | ❌ No access |
| Team deletion | ❌ Cannot delete |
| Invite users | ✅ Yes |
| Remove users | ✅ Yes (except Super User) |
| Manage integrations | ✅ Yes |
| Configure settings | ✅ Yes |
| View all data | ✅ Yes |
| Create/edit reports | ✅ Yes |
| Manage sites & contracts | ✅ Yes |
### User
Standard users have access to analytics features:
| Permission | Access |
| ------------------- | --------------- |
| Billing management | ❌ No access |
| Team deletion | ❌ Cannot delete |
| Invite users | ❌ No |
| Manage integrations | ❌ No |
| Configure settings | ❌ No |
| View all data | ✅ Yes |
| Create/edit reports | ✅ Yes |
| View user profiles | ✅ Yes |
## Role Comparison
| Capability | Super User | Admin | User |
| ---------------------- | :--------: | :---: | :--: |
| View analytics | ✅ | ✅ | ✅ |
| Create reports | ✅ | ✅ | ✅ |
| Create boards | ✅ | ✅ | ✅ |
| View user profiles | ✅ | ✅ | ✅ |
| Invite team members | ✅ | ✅ | ❌ |
| Remove team members | ✅ | ✅ | ❌ |
| Manage sites | ✅ | ✅ | ❌ |
| Manage contracts | ✅ | ✅ | ❌ |
| Configure auto-enhance | ✅ | ✅ | ❌ |
| Manage integrations | ✅ | ✅ | ❌ |
| Access billing | ✅ | ❌ | ❌ |
| Delete team | ✅ | ❌ | ❌ |
## Inviting Team Members
### Send Invitation
Navigate to **Settings** → **Team**
Click **Invite Team Member**
* Email address
* Select role (Admin or User)
Click **Send Invite**
The user receives an email with a link to join your team.
### Invitation Status
Track pending invitations:
```
Team Members:
├── john@example.com (Admin) - Active
├── jane@example.com (User) - Active
├── bob@example.com (User) - Pending (sent 2 days ago)
└── alice@example.com (Admin) - Pending (sent 1 hour ago)
```
### Resend or Cancel
For pending invitations:
* **Resend**: Send another invitation email
* **Cancel**: Remove the pending invitation
## Managing Team Members
### Change User Role
Admins and Super Users can change roles:
1. Go to **Settings** → **Team**
2. Find the user
3. Click role dropdown
4. Select new role (Admin or User)
You cannot change the Super User's role or demote yourself if you're the only Admin.
### Remove Team Member
1. Go to **Settings** → **Team**
2. Find the user to remove
3. Click **Remove** (trash icon)
4. Confirm removal
**What happens when removed:**
* User loses access immediately
* Personal saved reports become inaccessible
* Shared reports remain for the team
* User can be re-invited later
### Transfer Ownership
Currently, the Super User role cannot be transferred. Contact support if you need to change team ownership.
## Team Structure
### One Team, Multiple Sites
A single team can manage multiple sites:
```
Team: Acme Corp
├── Sites:
│ ├── acme-dex.com
│ ├── acme-nft.io
│ └── staging.acme-dex.com
│
├── Contracts:
│ ├── Acme Swap Router (ethereum)
│ ├── Acme NFT Collection (ethereum)
│ └── Acme Staking (polygon)
│
└── Team Members:
├── owner@acme.com (Super User)
├── dev@acme.com (Admin)
└── analyst@acme.com (User)
```
All team members have access to all sites and contracts within the team.
### Audit Logging
All team actions are logged:
```
Audit Log:
├── Feb 15, 2:30 PM │ owner@acme.com │ Invited dev@acme.com as Admin
├── Feb 15, 10:00 AM │ dev@acme.com │ Added site: staging.acme-dex.com
├── Feb 14, 4:45 PM │ owner@acme.com │ Changed analyst@acme.com role to User
└── Feb 14, 3:00 PM │ dev@acme.com │ Removed contract: Old Router
```
## Best Practices
### Role Assignment
```
✅ Recommended:
- 1 Super User (team owner, handles billing)
- 1-2 Admins (technical leads, manage settings)
- Remaining team as Users (analysts, marketers)
❌ Avoid:
- Everyone as Admin (security risk)
- No backup Admin (single point of failure)
```
### Access Management
* **Review regularly**: Audit team members quarterly
* **Remove promptly**: Remove access when people leave
* **Least privilege**: Give minimum necessary permissions
* **Document roles**: Keep track of who has what access
### Security
* Use strong passwords
* Enable 2FA when available
* Don't share accounts
* Use individual invitations (not shared links)
## Troubleshooting
1. Check spam/junk folder
2. Verify email address is correct
3. Resend the invitation
4. Try a different email address
* Only Super Users and Admins can change roles
* Cannot modify the Super User's role
* Cannot demote yourself if you're the last Admin
* Ask user to clear browser cache
* Session may take a few minutes to expire
* Contact support if issue persists
Contact Cryptique support to transfer the Super User role to another team member.
## Next Steps
Manage tracked sites and smart contracts
Data privacy settings
# Boards
Source: https://docs.cryptique.io/analysis/boards
Create dashboards to organize and share your analytics
## Overview
Boards are customizable dashboards that combine multiple visualizations, reports, and content into a single view. Use boards to monitor key metrics, share insights with your team, and tell data stories.
## Components
Boards can contain various types of components:
### Visualizations
Charts from your reports:
| Type | Description |
| ------------- | --------------------------------------------------------- |
| **Insights** | Line charts, bar charts, pie charts, tables, metric cards |
| **Funnels** | Funnel visualizations showing conversion |
| **Retention** | Retention tables and curves |
| **Flows** | Sankey diagrams showing user paths |
### Content Elements
| Element | Description |
| ------------ | -------------------------------------- |
| **Text** | Markdown-formatted text blocks |
| **Headers** | Section headers to organize your board |
| **Images** | Uploaded images or linked graphics |
| **Videos** | Embedded video content |
| **Dividers** | Visual separators between sections |
## Creating a Board
Navigate to **Boards** and click **New Board**
Click **+ Add** to add visualizations or content:
* **Add Report**: Insert a saved report
* **Add Text**: Insert text/markdown
* **Add Image**: Upload or link an image
* **Add Video**: Embed a video
* **Add Divider**: Insert a visual break
Drag and drop components to arrange them. Resize by dragging edges.
Click **Save** and give your board a name
## Adding Reports to Boards
### From a Report
1. Build or open a saved report
2. Click **Add to Board**
3. Select existing board or create new
4. Report appears on the board
### From the Board
1. Open your board
2. Click **+ Add** → **Add Report**
3. Browse or search saved reports
4. Select and position the report
## Layout & Styling
### Grid System
Boards use a flexible grid for layout:
```
┌─────────────────────────────────────────────────┐
│ [Header: KPIs] │
├──────────────────┬──────────────────────────────┤
│ │ │
│ Metric Card │ Line Chart │
│ (1x1) │ (2x1) │
│ │ │
├──────────────────┼──────────────────────────────┤
│ │ │
│ Pie Chart │ Funnel │
│ (1x1) │ (2x1) │
│ │ │
├──────────────────┴──────────────────────────────┤
│ [Divider] │
├─────────────────────────────────────────────────┤
│ │
│ Retention Table (3x1) │
│ │
└─────────────────────────────────────────────────┘
```
### Resizing Components
* Drag corner/edges to resize
* Snap to grid for alignment
* Minimum sizes vary by component type
### Reordering
* Drag components to new positions
* Components shift to accommodate
* Use dividers to create sections
## Sharing Boards
### Team Sharing
Share with specific team members:
1. Click **Share** on your board
2. Enter team member emails
3. Set permissions:
* **View**: Can see but not edit
* **Edit**: Can modify the board
### Public Links
Create view-only public links:
1. Click **Share** → **Create Public Link**
2. Copy the generated URL
3. Anyone with the link can view (not edit)
Public links show a snapshot of the data. Consider data sensitivity before sharing externally.
## Board Permissions
| Role | View | Edit | Share | Delete |
| ----------- | ---- | ---- | ----- | ------ |
| Owner | ✅ | ✅ | ✅ | ✅ |
| Editor | ✅ | ✅ | ❌ | ❌ |
| Viewer | ✅ | ❌ | ❌ | ❌ |
| Public Link | ✅ | ❌ | ❌ | ❌ |
## Example Boards
### Executive Dashboard
```
┌─────────────────────────────────────────────────┐
│ [Header] Key Metrics This Week │
├────────┬────────┬────────┬─────────────────────┤
│ WAU │ Txns │ Volume │ Conversion Rate │
│ 12.5K │ 45.2K │ $2.3M │ 8.5% │
├────────┴────────┴────────┴─────────────────────┤
│ │
│ Weekly Active Users (Line Chart) │
│ │
├─────────────────────────────────────────────────┤
│ │
│ Transaction Volume by Chain (Bar Chart) │
│ │
└─────────────────────────────────────────────────┘
```
### Acquisition Board
```
┌─────────────────────────────────────────────────┐
│ [Header] Marketing Performance │
├─────────────────────────────────────────────────┤
│ │
│ Traffic Source → Wallet Connect Funnel │
│ │
├──────────────────┬──────────────────────────────┤
│ │ │
│ By Source (Pie) │ Conversion by Source (Bar) │
│ │ │
├──────────────────┴──────────────────────────────┤
│ │
│ Post-Wallet Connect Flows (Sankey) │
│ │
└─────────────────────────────────────────────────┘
```
### Product Health Board
```
┌─────────────────────────────────────────────────┐
│ [Header] User Engagement │
├──────────────────┬──────────────────────────────┤
│ │ │
│ DAU/WAU Ratio │ 7-Day Retention Curve │
│ │ │
├──────────────────┴──────────────────────────────┤
│ │
│ Weekly Retention Table │
│ │
├─────────────────────────────────────────────────┤
│ │
│ Feature Usage by User Segment (Stacked Bar) │
│ │
└─────────────────────────────────────────────────┘
```
## Best Practices
### Organize Logically
Group related metrics together:
```
✅ Good organization:
- KPIs at top
- Detailed breakdowns below
- Related metrics grouped
- Clear section headers
❌ Poor organization:
- Random metric placement
- No visual hierarchy
- Missing context
```
### Design for Your Audience
```
Executive board:
- High-level KPIs
- Trend lines
- Minimal detail
Analyst board:
- Detailed breakdowns
- Multiple dimensions
- Tables with raw data
Team board:
- Actionable metrics
- Target comparisons
- Recent changes
```
### Keep It Focused
```
✅ Good: 5-8 focused components per board
→ Easy to scan, clear story
❌ Avoid: 20+ components crammed together
→ Information overload
```
### Use Text for Context
Add explanatory text:
```
[Header] Conversion Funnel
[Text] This week's funnel shows a 15% improvement in
wallet-to-transaction conversion. The main driver is
our new onboarding flow launched on Monday.
[Funnel Chart]
```
### Refresh Considerations
Board data refreshes when viewed. For large boards:
* Consider splitting into multiple boards
* Use summary views for dashboards
* Link to detailed reports
## Managing Boards
### Duplicating
1. Open board
2. Click **...** → **Duplicate**
3. Modify the copy as needed
### Deleting
1. Open board
2. Click **...** → **Delete**
3. Confirm deletion
Deleting a board is permanent. The saved reports within are not deleted—only removed from the board.
### Organizing
Use folders or naming conventions:
```
Boards:
├── [Exec] Weekly KPIs
├── [Exec] Monthly Review
├── [Product] Feature Adoption
├── [Product] User Flows
├── [Marketing] Campaign Performance
└── [Marketing] Channel Analysis
```
## Next Steps
Create charts for your board
Segment data on boards
# Cohorts
Source: https://docs.cryptique.io/analysis/cohorts
Create and manage user segments for targeted analysis
## Overview
Cohorts are dynamic user segments based on behaviors or attributes. Use cohorts to compare user groups, filter reports, and understand how different segments perform.
## What Are Cohorts?
A cohort is a saved definition of "users who match these criteria":
```
Cohort: "Power Traders"
Definition:
├── Has done: swap_completed
│ └── At least 10 times
│ └── In the last 30 days
├── AND user property: is_whale = true
```
**Dynamic**: Cohorts automatically update as users match or unmatch the criteria.
## Creating Cohorts
### Visual Query Builder
Build cohorts with the intuitive AND/OR interface:
Navigate to **Cohorts** → **New Cohort**
Click **Add Criteria** and choose:
* **Event**: Users who did (or didn't do) an event
* **User Property**: Users with specific attributes
* **Cohort**: Users in another cohort
```
┌────────────────────────────────────────┐
│ Users who: │
│ │
│ [Did] [swap_completed] [at least 5x] │
│ │
│ ── AND ── │
│ │
│ [Have property] [plan] [=] [pro] │
│ │
│ ── OR ── │
│ │
│ [Did] [premium_feature_used] │
└────────────────────────────────────────┘
```
Preview matching users count, then save with a name
### Criteria Types
#### Event-Based Criteria
```
Users who:
├── Did [event_name]
│ ├── Frequency: at least N times / exactly N times / at most N times
│ ├── Time frame: in the last N days / between dates / ever
│ └── Where: [property filters]
│
└── Did NOT do [event_name]
└── Time frame: in the last N days / ever
```
Examples:
```
✓ Did "swap_completed" at least 5 times in the last 30 days
✓ Did NOT do "wallet_connect" in the last 7 days
✓ Did "transaction" where chain = "ethereum"
```
#### Property-Based Criteria
```
Users where:
├── [property_name] [operator] [value]
│
│ Operators:
│ ├── String: is, is_not, contains, is_set, is_not_set
│ ├── Number: =, ≠, >, ≥, <, ≤, between
│ └── Boolean: is_true, is_false
```
Examples:
```
✓ plan is "pro"
✓ wallet_age_days > 365
✓ is_web3_user is_true
✓ email is_set
```
#### Cohort-Based Criteria
Nest cohorts for complex segments:
```
Users who:
├── Are in cohort "Active Traders"
├── AND are NOT in cohort "Churned Users"
```
### AND/OR Logic
Combine criteria with logical operators:
**AND** (all must be true):
```
Users who:
├── Did swap_completed (5+ times)
├── AND country = "US"
├── AND plan = "pro"
```
**OR** (any can be true):
```
Users who:
├── Did swap_completed (5+ times)
├── OR did liquidity_added
├── OR total_volume > 10000
```
**Nested logic**:
```
Users who:
├── (Did swap_completed AND chain = "ethereum")
├── OR
├── (Did swap_completed AND chain = "polygon" AND count >= 10)
```
## Dynamic Cohorts
Cohorts are **dynamic**—they auto-update as users match or unmatch criteria.
```
Day 1:
"Active Traders" cohort: 500 users
Day 7:
- 50 new users matched (traded 5+ times)
- 30 users unmatched (30-day window moved)
"Active Traders" cohort: 520 users
```
**Recomputed**: On each query, ensuring up-to-date membership.
## Using Cohorts
### In Reports
Filter any report by cohort:
```
Insights Report:
├── Event: swap_completed
├── Filter: Cohort = "Power Traders"
└── See metrics for only power traders
```
### In Funnels
Compare conversion across cohorts:
```
Funnel: Landing → Wallet → Transaction
├── Cohort A: "Twitter Users" → 8% conversion
├── Cohort B: "Discord Users" → 15% conversion
└── Cohort C: "Organic" → 12% conversion
```
### In Retention
Analyze retention by cohort:
```
Retention:
├── Birth: First transaction
├── Return: Any transaction
├── Filter: Cohort = "High-Value Users"
└── See retention for high-value segment
```
### In Breakdowns
Break down metrics by cohort:
```
Breakdown by cohort:
├── Power Traders: 45% of volume
├── Casual Users: 35% of volume
└── New Users: 20% of volume
```
## Example Cohorts
### By Activity Level
```
"Power Users"
├── Did any_event at least 50 times
├── In the last 30 days
"Casual Users"
├── Did any_event at least 5 times
├── AND at most 20 times
├── In the last 30 days
"At-Risk Users"
├── Did any_event in the last 90 days
├── AND did NOT do any_event in the last 14 days
```
### By Transaction Behavior
```
"Whales"
├── User property: total_volume_usd > 100000
├── OR did transaction where value > 10 ETH
"Multi-Chain Users"
├── Did transaction where chain = "ethereum"
├── AND did transaction where chain = "polygon"
├── AND did transaction where chain = "arbitrum"
"New Transactors"
├── Did transaction
├── In the last 7 days
├── AND did NOT do transaction before 7 days ago
```
### By Lifecycle
```
"New Users (This Week)"
├── User property: first_seen in the last 7 days
"Completed Onboarding"
├── Did onboarding_completed
"Churned"
├── Did any_event in the last 90 days
├── AND did NOT do any_event in the last 30 days
```
### By Source
```
"Twitter Acquisition"
├── User property: utm_source = "twitter"
├── OR initial_referrer contains "twitter.com"
"Organic Search"
├── User property: utm_medium = "organic"
├── OR initial_referrer contains "google.com"
├── OR initial_referrer contains "bing.com"
```
### Web3-Specific
```
"DeFi Power Users"
├── Did swap_completed at least 10 times
├── AND did liquidity_added at least once
├── In the last 30 days
"NFT Collectors"
├── Did nft_purchased at least 3 times
├── OR user property: nft_count > 10
"Wallet Veterans"
├── User property: wallet_age_days > 365
├── AND user property: total_transaction_count > 100
```
## Managing Cohorts
### Viewing Membership
See current cohort members:
```
"Power Traders" - 523 users
├── user_12345 (matched 3 days ago)
├── user_67890 (matched 1 week ago)
├── 0x1234...abcd (matched 2 weeks ago)
└── ... (521 more)
```
### Editing Cohorts
1. Open cohort
2. Modify criteria
3. Preview new membership count
4. Save changes
Editing a cohort affects all reports using it. Changes apply immediately.
### Deleting Cohorts
1. Open cohort
2. Click **Delete**
3. Confirm (cannot be undone)
Reports using a deleted cohort will show errors. Update or remove cohort filters before deleting.
## Best Practices
### Name Descriptively
```
✅ Good names:
"Active Traders (30d, 5+ swaps)"
"High-Value Users (>$10k volume)"
"Twitter Acquisition - Q1 2024"
❌ Poor names:
"Cohort 1"
"Test"
"Users"
```
### Keep Criteria Focused
```
✅ Focused:
Users who swapped 10+ times in 30 days
❌ Overly complex:
Users who swapped 10+ times AND visited docs
AND have pro plan AND from US AND connected MetaMask
AND wallet age > 180 days AND...
```
### Document Logic
Add descriptions to cohorts:
```
Name: "Churn Risk"
Description: Users active 30-90 days ago but not in last 30 days.
Use for win-back campaigns.
```
### Review Periodically
Cohort definitions may need updates:
* Feature renames (event names change)
* Business logic changes
* Criteria become too broad/narrow
## Next Steps
All filter options
Use cohorts in reports
# Filters & Operators
Source: https://docs.cryptique.io/analysis/filters-and-operators
Complete reference for filter operators by data type
## Overview
Filters let you narrow down data to specific segments. Cryptique provides a visual query builder with AND/OR logic and type-specific operators for precise filtering.
## Filter Types
You can filter by five categories:
| Filter Type | Description | Example |
| ------------------------ | ----------------------------------- | -------------------------------------------- |
| **Event Filters** | Filter by event name and properties | Events where `event_name = "swap_completed"` |
| **User Profile Filters** | Filter by user properties | Users where `plan = "pro"` |
| **Transaction Filters** | Filter on-chain transactions | Transactions where `chain = "ethereum"` |
| **Time Filters** | Filter by date/time ranges | Events in `last 30 days` |
| **Cohort Filters** | Filter by cohort membership | Users in `"Power Users"` cohort |
## Query Builder
Cryptique uses a visual query builder with AND/OR logic:
```
Filter where:
├── event_name = "swap_completed"
├── AND chain = "ethereum"
└── OR (
├── amount_usd > 1000
└── AND user_tier = "whale"
)
```
Combine conditions with:
* **AND**: All conditions must be true
* **OR**: At least one condition must be true
* **Grouping**: Nest conditions for complex logic
## String Operators
For text properties like `country`, `browser_name`, `event_name`:
| Operator | Description | Example |
| ------------------ | -------------------------- | ------------------------------- |
| `is` | Exact match | `country is "US"` |
| `is_not` | Does not equal | `country is_not "US"` |
| `contains` | Contains substring | `email contains "@gmail"` |
| `does_not_contain` | Does not contain substring | `email does_not_contain "test"` |
| `is_set` | Property has any value | `email is_set` |
| `is_not_set` | Property has no value | `email is_not_set` |
### String Examples
```
# Exact match
country is "United States"
# Exclude specific value
browser_name is_not "Safari"
# Partial match
current_url contains "/swap"
page_title contains "Dashboard"
# Check existence
wallet_address is_set # Only Web3 users
email is_not_set # Anonymous users
```
## Number Operators
For numeric properties like `amount_usd`, `transaction_count`, `session_duration`:
| Operator | Description | Example |
| -------------------- | ----------------------- | --------------------------------- |
| `equal` | Equals | `amount equal 100` |
| `not_equal` | Does not equal | `amount not_equal 0` |
| `greater_than` | Greater than | `amount greater_than 100` |
| `greater_than_equal` | Greater than or equal | `amount greater_than_equal 100` |
| `less_than` | Less than | `amount less_than 1000` |
| `less_than_equal` | Less than or equal | `amount less_than_equal 1000` |
| `between` | In range (inclusive) | `amount between 100 and 1000` |
| `not_between` | Outside range | `amount not_between 100 and 1000` |
| `is_numeric` | Has a numeric value | `price is_numeric` |
| `is_not_numeric` | Not a number (null/NaN) | `price is_not_numeric` |
### Number Examples
```
# Exact value
transaction_count equal 0 # Users with no transactions
# Comparisons
amount_usd greater_than 1000 # High-value transactions
gas_used less_than 100000 # Low gas transactions
# Range filtering
amount_usd between 100 and 10000 # Mid-tier transactions
session_duration not_between 0 and 10 # Exclude bounces
# Existence checks
token_balance is_numeric # Has balance data
```
## Boolean Operators
For true/false properties like `is_web3_user`, `has_completed_onboarding`:
| Operator | Description | Example |
| ---------- | ----------------- | ----------------------- |
| `is_true` | Property is true | `is_web3_user is_true` |
| `is_false` | Property is false | `is_web3_user is_false` |
### Boolean Examples
```
# Web3 users only
is_web3_user is_true
# Traditional Web2 users
is_web3_user is_false
# Custom boolean properties
has_completed_onboarding is_true
is_verified is_false
```
## Datetime Operators
For date/time properties like `timestamp`, `created_at`, `last_seen`:
| Operator | Description | Example |
| ----------------- | ---------------------------- | ---------------------------------------- |
| `last` | Within the last N days/hours | `timestamp last 7 days` |
| `not_in_the_last` | Not within the last N days | `timestamp not_in_the_last 7 days` |
| `between` | Between two dates | `timestamp between Jan 1 and Jan 31` |
| `not_between` | Outside date range | `timestamp not_between Jan 1 and Jan 31` |
| `on` | On specific date | `timestamp on Jan 15` |
| `not_on` | Not on specific date | `timestamp not_on Jan 1` |
| `before_the_last` | Before the last N days | `timestamp before_the_last 30 days` |
| `before` | Before specific date | `timestamp before Jan 1, 2024` |
| `since` | Since specific date | `timestamp since Jan 1, 2024` |
| `in_the_next` | Within the next N days | `expiry_date in_the_next 7 days` |
### Datetime Examples
```
# Relative time filters
timestamp last 30 days # Last month's activity
timestamp last 24 hours # Today's events
created_at not_in_the_last 90 days # Older users only
# Date range
timestamp between "2024-01-01" and "2024-01-31"
timestamp not_between "2024-12-24" and "2024-12-26" # Exclude holidays
# Specific date
timestamp on "2024-01-15" # Single day
timestamp not_on "2024-01-01" # Exclude New Year
# Before/after
timestamp before "2024-06-01" # Before June
timestamp since "2024-01-01" # This year only
first_seen before_the_last 365 days # Users over a year old
# Future dates (for expiry, subscription end, etc.)
subscription_end in_the_next 30 days # Expiring soon
```
## List Operators
For array properties like `chains_used`, `tokens_held`, `tags`:
| Operator | Description | Example |
| ------------- | ---------------- | -------------------------------------------------- |
| `any_in_list` | Any item matches | `chains_used any_in_list ["ethereum", "polygon"]` |
| `all_in_list` | All items match | `required_tags all_in_list ["verified", "active"]` |
List operators can be combined with **nested operators** based on item type:
### List with String Items
```
# Any chain is ethereum OR polygon
chains_used any_in_list where item is "ethereum" OR item is "polygon"
# User has used any EVM chain
chains_used any_in_list where item contains "evm"
# All tags must be from approved list
tags all_in_list where item is "verified" OR item is "premium"
```
### List with Number Items
```
# Any transaction over $1000
transaction_amounts any_in_list where item greater_than 1000
# All balances are positive
token_balances all_in_list where item greater_than 0
```
## Filter Combinations
### AND Logic
All conditions must be true:
```
Events where:
├── event_name is "swap_completed"
├── AND chain is "ethereum"
├── AND amount_usd greater_than 100
└── AND timestamp last 7 days
→ Only Ethereum swaps over $100 in the last week
```
### OR Logic
At least one condition must be true:
```
Users where:
├── plan is "pro"
└── OR total_transactions greater_than 100
→ Pro users OR users with 100+ transactions
```
### Nested Groups
Combine AND/OR with grouping:
```
Events where:
├── event_name is "swap_completed"
└── AND (
├── chain is "ethereum"
└── OR chain is "arbitrum"
)
└── AND (
├── amount_usd greater_than 1000
└── OR user_tier is "whale"
)
→ Swaps on Ethereum or Arbitrum that are either
high-value ($1000+) or from whale users
```
## Event Filters
Filter events by name and properties:
```
Events:
├── event_name is "swap_completed"
├── Properties:
│ ├── input_token is "ETH"
│ ├── AND output_token is "USDC"
│ └── AND slippage less_than 1
```
### Common Event Filters
| Filter | Use Case |
| ---------------------------------------- | ------------------------ |
| `event_name is "wallet_connect"` | Only wallet connections |
| `event_category is "transaction"` | Only transaction events |
| `custom_properties.campaign is "summer"` | Campaign-specific events |
## User Profile Filters
Filter by user attributes:
```
Users:
├── plan is "pro"
├── AND country is "US"
├── AND is_web3_user is_true
└── AND wallet_address is_set
```
### Common User Filters
| Filter | Use Case |
| ------------------------------- | ---------------------------- |
| `is_web3_user is_true` | Web3 users only |
| `first_seen last 30 days` | New users |
| `session_count greater_than 10` | Engaged users |
| `wallet_address is_set` | Users with connected wallets |
## Transaction Filters
Filter on-chain transactions:
```
Transactions:
├── chain is "ethereum"
├── AND contract_name is "Swap Router"
├── AND method_name is "swapExactTokensForTokens"
└── AND value greater_than 0
```
### Common Transaction Filters
| Filter | Use Case |
| ----------------------------- | ----------------------- |
| `chain is "ethereum"` | Ethereum transactions |
| `status is "confirmed"` | Successful transactions |
| `gas_price less_than 50` | Low gas transactions |
| `method_name contains "swap"` | Swap transactions |
## Cohort Filters
Filter by cohort membership:
```
Users:
├── IN cohort "Power Users"
└── AND NOT IN cohort "Churned Users"
```
Cohort filters are particularly useful for:
* Comparing behavior across segments
* Excluding specific user groups
* Analyzing high-value users
## Time Filters
Every report supports time range selection:
```
Time Range: Last 30 days
Granularity: Daily
OR
Custom Range: Jan 1, 2024 - Jan 31, 2024
Granularity: Weekly
```
See [Time Controls](/analysis/time-controls) for detailed time range options.
## Saved Filters
Save frequently used filters for reuse:
1. Build your filter combination
2. Click **Save Filter**
3. Name it descriptively: "US Pro Web3 Users"
4. Apply to any report with one click
## Best Practices
### Be Specific
```
✅ Good: event_name is "swap_completed" AND chain is "ethereum"
❌ Vague: event_name contains "swap"
```
### Use Appropriate Operators
```
✅ For exact match: is / equal
✅ For ranges: between / greater_than
✅ For text search: contains
❌ Using contains for exact values
❌ Using is for partial matches
```
### Test Filter Results
Before building complex reports, verify your filters:
1. Apply filter to simple metric (total events)
2. Check count makes sense
3. Spot-check sample records if possible
### Document Complex Filters
For complex nested logic, add comments:
```
# High-value users: Pro plan OR whale behavior
Users where:
├── plan is "pro" # Paying customers
└── OR (
├── total_volume greater_than 100000 # High volume
└── AND transaction_count greater_than 50 # Active
)
```
## Next Steps
Segment data by properties
Configure time ranges
# Flows
Source: https://docs.cryptique.io/analysis/reports/flows
Visualize the paths users take through your product
## Overview
Flows (also called Sankey diagrams) visualize the paths users take through your product. See what users do before and after any event, discover common patterns, and identify unexpected behaviors.
## Use Cases
* What do users do after connecting their wallet?
* What actions lead to a first transaction?
* Where do users go after viewing the pricing page?
* Where do users go instead of converting?
* What do users do after abandoning checkout?
* Why are users leaving the swap page?
* How do users discover feature X?
* What's the typical path to becoming a power user?
* Do users explore multiple chains before settling?
## Quick Start
Choose the event to center your analysis:
```
Starting Event: wallet_connect
```
Analyze what happens before, after, or both:
```
Direction: Steps After
Number of steps: 5
```
* Set number of steps to show
* Choose to hide specific events
* Apply breakdowns
Identify common paths and unexpected behaviors
## Flow Directions
### Steps After
See what users do **after** an event:
```mermaid theme={null}
flowchart LR
A[wallet_connect] --> B[swap_completed 40%]
A --> C[page_view: /pools 25%]
A --> D[page_view: /docs 20%]
A --> E[session_end 15%]
```
**Use for:**
* Understanding what users do after key milestones
* Identifying next-step opportunities
* Finding unexpected behaviors
### Steps Before
See what users do **before** an event:
```mermaid theme={null}
flowchart LR
A[page_view: /landing 30%] --> E[wallet_connect]
B[page_view: /docs 25%] --> E
C[referral_link 25%] --> E
D[direct_visit 20%] --> E
```
**Use for:**
* Understanding what leads to conversions
* Identifying effective entry points
* Discovering successful paths
### Steps Before & After
See the complete journey around an event:
```mermaid theme={null}
flowchart LR
subgraph Before["Before"]
A1[landing 30%]
A2[docs 25%]
A3[referral 25%]
A4[direct 20%]
end
subgraph Event["Event"]
B[wallet_connect]
end
subgraph After["After"]
C1[swap_init 40%]
C2[pool_view 25%]
C3[docs 20%]
C4[leave 15%]
end
A1 --> B
A2 --> B
A3 --> B
A4 --> B
B --> C1
B --> C2
B --> C3
B --> C4
```
**Use for:**
* Complete journey understanding
* Before/after comparisons
* Holistic flow analysis
## Reading Flow Diagrams
### Sankey Structure
```mermaid theme={null}
flowchart LR
A[Event A 1000 users] --> B[Event B 500 users, 50%]
A --> C[Event C 300 users, 30%]
A --> D[Event D 200 users, 20%]
```
**Wider paths** = More users taking that route
**Percentages** = Share of users from previous step
### Multi-Step Flows
```mermaid theme={null}
flowchart LR
subgraph Step1["Step 1"]
A[connect]
end
subgraph Step2["Step 2"]
B1[swap]
B2[pool]
B3[leave]
end
subgraph Step3["Step 3"]
C1[success 80%]
C2[fail 20%]
C3[add_liq 60%]
C4[leave 40%]
C5[end]
end
A --> B1
B1 --> C1
B1 --> C2
A --> B2
B2 --> C3
B2 --> C4
A --> B3
B3 --> C5
```
## Configuration Options
### Number of Steps
Control how many steps to display:
```
1 step: Immediate next action only
3 steps: Short journey
5 steps: Medium journey (recommended)
10 steps: Full exploration
```
### Hide Events
Remove noise by hiding irrelevant events:
```
Hide events:
- page_view (too noisy)
- scroll (not meaningful)
- mouse_move (irrelevant)
Keep:
- wallet_connect
- swap_completed
- transaction
```
### Breakdown by Property
Split flows by a property:
```
Breakdown: device_type
Mobile:
connect → swap (25%) → success
Desktop:
connect → swap (45%) → success
→ Desktop users convert better!
```
## Filters
Focus on specific user segments or behaviors:
### Event Filters
Filter the starting event:
```
Starting Event: wallet_connect
└── where: wallet_type = "metamask"
Only MetaMask connections
```
### User Filters
Filter by user properties:
```
User Filter:
├── country = "US"
├── AND plan = "pro"
US Pro users only
```
### Time Filters
Analyze specific periods:
```
Time Range: Last 30 days
Granularity: Daily
See recent behavior patterns
```
## Web3 Flow Examples
### Post-Wallet Connection
**Starting Event:** `wallet_connect` · **Direction:** 5 Steps After
```mermaid theme={null}
flowchart TB
A[wallet_connect] --> B[swap_initiated 40%]
A --> C[pool_viewed 25%]
A --> D[docs_viewed 20%]
A --> E[session_end 15%]
B --> B1[transaction swap 75%]
C --> C1[liquidity_added 50%]
D --> D1[wallet_connect 30%]
```
### Pre-Transaction Path
**Starting Event:** Transaction (any) · **Direction:** 5 Steps Before
```mermaid theme={null}
flowchart TB
A1[token_selected 90%] --> A2[swap_quoted 85%] --> A3[swap_initiated 60%] --> T[Transaction]
B1[pool_viewed 75%] --> B2[liquidity_add_clicked 20%] --> T
C1[staking_page_viewed 80%] --> C2[stake_clicked 20%] --> T
```
### Cross-Chain Exploration
**Starting Event:** `chain_changed` · **Breakdown:** new\_chain
```mermaid theme={null}
flowchart LR
subgraph Before["Before → Arbitrum"]
A1[swap_failed Ethereum 40%]
A2[price_comparison_viewed 35%]
A3[gas_estimate_viewed 25%]
end
E[chain_changed]
subgraph After["After"]
B1[swap_completed 65%]
B2[returned_to_ethereum 35%]
end
A1 --> E
A2 --> E
A3 --> E
E --> B1
E --> B2
```
### NFT Journey
**Starting Event:** `nft_viewed` · **Filter:** collection = "CoolCats"
```mermaid theme={null}
flowchart TB
A[nft_viewed] --> B[additional_nft_viewed 35%]
A --> C[wallet_connect 30%]
A --> D[collection_explored 20%]
A --> E[session_end 15%]
C --> C1[mint_initiated 60%]
C1 --> C2[transaction mint 70%]
```
## Analyzing Flows
### Identifying Patterns
**High-Volume Paths:**
Look for the thickest flows—these are your main user journeys.
```
If 60% of users go: landing → docs → wallet_connect
→ Optimize this path! It's your main funnel.
```
**Unexpected Paths:**
Look for surprising flows.
```
If 20% of users go: checkout → settings → checkout
→ Are they looking for payment options?
```
### Identifying Drop-Off
**Exit Points:**
Where do users leave?
```mermaid theme={null}
flowchart LR
A[swap_initiated] --> B[session_end 25%]
```
→ Users leaving before completing—investigate UX
**Detours:**
Where do users go instead of converting?
```mermaid theme={null}
flowchart LR
subgraph Expected["Expected"]
A1[swap_page] --> B1[swap_completed]
end
subgraph Actual["Actual"]
A2[swap_page] --> B2[docs 40%]
end
```
→ Users need more information before swapping
### Comparing Segments
Use breakdowns to compare:
```mermaid theme={null}
flowchart TB
subgraph Mobile["Mobile after wallet_connect"]
M[wallet_connect] --> M1[swap 25%]
M --> M2[leave 40%]
M --> M3[browse 35%]
end
subgraph Desktop["Desktop after wallet_connect"]
D[wallet_connect] --> D1[swap 45%]
D --> D2[leave 20%]
D --> D3[browse 35%]
end
```
→ Mobile users leaving more—mobile UX issue?
## Best Practices
### Choose Meaningful Starting Events
```
✅ Good starting events:
- wallet_connect (key milestone)
- purchase_completed (conversion point)
- feature_used (engagement signal)
- signup_completed (lifecycle event)
❌ Poor starting events:
- page_view (too broad)
- click (too generic)
- scroll (not meaningful)
```
### Hide Noise
Remove events that obscure patterns:
```
Hide:
- Generic page_views (keep specific ones)
- Scroll events
- Mouse events
- Internal/system events
```
### Use Appropriate Step Counts
```
Immediate impact: 1-2 steps
Journey analysis: 3-5 steps
Full exploration: 5-10 steps
More steps = more complexity
Start small, expand as needed
```
### Segment Meaningfully
```
✅ Actionable breakdowns:
- device_type (fix mobile?)
- traffic_source (optimize channel?)
- user_tier (different needs?)
❌ Not actionable:
- random_id
- timestamp
```
## Saving & Sharing
### Save Flow
1. Configure your flow analysis
2. Click **Save**
3. Name it: "Post-Wallet Connect Journey"
### Add to Board
Include flows in dashboards for ongoing monitoring. All saved flows can be added to boards.
## Next Steps
Create dashboards with flows
Analyze flows for specific segments
# Funnels
Source: https://docs.cryptique.io/analysis/reports/funnels
Measure conversion through a series of steps
## Overview
Funnels measure how users progress through a sequence of events. Track conversion rates, identify drop-off points, and understand how long users take to complete multi-step processes.
In Cryptique, funnels are uniquely powerful because they can combine **off-chain events** (website behavior) with **on-chain transactions** (blockchain activity).
## Use Cases
* What percent of users who view the swap page actually swap?
* Where do users drop off in the onboarding flow?
* How does mobile conversion compare to desktop?
* What percent of wallet connections lead to transactions?
* How long from first visit to first on-chain transaction?
* Which traffic sources have the highest transaction conversion?
* How many users who try feature X go on to use feature Y?
* What's the path from free to paid?
* Do users who complete onboarding transact more?
## Quick Start
Add events in order. Each step must happen after the previous:
```
Step 1: page_view (landing page)
Step 2: wallet_connect
Step 3: swap_initiated
Step 4: Transaction: swapExactTokensForTokens
```
Choose how long users have to complete the funnel:
* 1 hour, 1 day, 7 days, 30 days, etc.
* **Conversion Rate**: Percentage completing all steps
* **Unique Users**: Count at each step
* **Time to Convert**: Average time between steps
Filter to specific user segments or time periods
See how conversion varies by property
## Funnel Structure
### Steps
Each funnel step is an event or transaction:
```mermaid theme={null}
flowchart LR
S1[Step 1: page_view uri = /swap] --> S2[Step 2: wallet_connect]
S2 --> S3[Step 3: swap_initiated input_token = ETH]
S3 --> S4[Step 4: Transaction swapExactTokensForTokens Swap Router]
```
### Conversion Window
Users must complete all steps within the window:
```mermaid theme={null}
flowchart TB
subgraph UserA["User A — Converted ✓"]
A1[Day 1: page_view] --> A2[Day 3: wallet_connect] --> A3[Day 5: swap_initiated] --> A4[Day 6: Transaction]
end
subgraph UserB["User B — Not converted ✗"]
B1[Day 1: page_view] --> B2[Day 2: wallet_connect]
B2 -.->|Day 10: too late| B3[swap_initiated ✗]
end
```
**Conversion Window: 7 days** — User A completed in 6 days; User B missed the window.
### Step Order
Steps must occur in the defined order:
```mermaid theme={null}
flowchart LR
A[Step 1: A] --> B[Step 2: B] --> C[Step 3: C] --> OK[Converted ✓]
```
**Valid:** A → B → C
```mermaid theme={null}
flowchart LR
A2[A] --> C2[C] --> B2[B]
B3[B] --> A3[A] --> C3[C]
```
**Invalid:** A → C → B or B → A → C (order matters)
## Measurements
### Conversion Rate
Percentage of users who complete each step:
```mermaid theme={null}
flowchart LR
S1[Step 1 10,000 users 100%] --> S2[Step 2 3,500 users 35%] --> S3[Step 3 1,200 users 12%] --> S4[Step 4 800 users 8%]
```
**Overall Conversion: 8%**
### Step-by-Step Rate
Conversion from each step to the next:
```
├── Step 1 → Step 2: 35% (3,500 / 10,000)
├── Step 2 → Step 3: 34% (1,200 / 3,500)
└── Step 3 → Step 4: 67% (800 / 1,200)
```
### Time to Convert
How long users take between steps:
```
Average time:
├── Step 1 → Step 2: 2.5 hours
├── Step 2 → Step 3: 15 minutes
├── Step 3 → Step 4: 5 minutes
└── Total: 2 hours 50 minutes
```
## Filters
Filter your funnel to specific segments:
### Global Filters
Apply to all steps:
```
Filter: country = "US" AND device_type = "mobile"
All steps will only include US mobile users
```
### Step-Specific Filters
Apply to individual steps:
```
Step 1: page_view
└── where: uri = "/swap" (step filter)
Step 2: wallet_connect
└── where: wallet_type = "metamask" (step filter)
```
### User Property Filters
Filter by user attributes:
```
Filter: Users where
├── plan = "pro"
├── AND wallet_age_days > 30
└── AND is_whale = false
```
## Breakdowns
See how conversion varies across segments:
### Property Breakdown
```
Funnel by utm_source:
├── twitter: 12% conversion
├── discord: 18% conversion
├── google: 8% conversion
└── direct: 15% conversion
```
### Cohort Breakdown
```
Funnel by user type:
├── Whales: 25% conversion
├── Active traders: 15% conversion
└── New users: 6% conversion
```
## Visualizations
### Funnel Steps View
See the funnel as a visual diagram:
```mermaid theme={null}
flowchart LR
L[Landing Page 10,000 · 100%] --> W[Wallet Connect 3,500 · 35%]
W --> S[Swap Init 1,200 · 12%]
S --> T[Transaction 800 · 8%]
```
*65% drop → 23% drop → 4% drop between steps*
### Line Chart
See conversion trend over time:
```
Overall conversion rate by week:
├── Week 1: 7%
├── Week 2: 8%
├── Week 3: 9%
└── Week 4: 8%
```
### Bar Chart
Compare conversion across segments:
```
Conversion by chain:
├── Ethereum: 12%
├── Polygon: 15%
├── Arbitrum: 18%
└── Base: 14%
```
## Advanced Features
### Conversion Criteria
**Ordered Steps** (default):
Users must complete steps in exact order.
```
A → B → C required
A → C → B does not convert
```
**Any Order**:
Steps can happen in any sequence within window.
```
A, B, C required (any order)
A → C → B converts ✓
C → A → B converts ✓
```
### Counting Methods
**Unique Users** (default):
Each user counted once, on first entry:
```
User enters funnel multiple times:
├── Monday: Enters at Step 1
├── Tuesday: Enters at Step 1 again
└── → Only Monday entry counted
```
**Totals**:
Count all funnel entries:
```
User enters funnel multiple times:
├── Monday: Entry 1
├── Tuesday: Entry 2
└── → Both entries counted
```
### Time to Convert Distribution
See how conversion time varies:
```
Time to complete funnel:
├── < 1 hour: 45%
├── 1-4 hours: 25%
├── 4-24 hours: 15%
├── 1-3 days: 10%
└── > 3 days: 5%
```
### Hold Property Constant
Require a property to be the same across steps:
```
Hold constant: input_token
User swaps ETH in step 1, must swap ETH in transaction:
├── Step 1: swap_initiated (input_token = "ETH")
└── Step 4: Transaction with ETH → Counts ✓
├── Step 1: swap_initiated (input_token = "ETH")
└── Step 4: Transaction with MATIC → Does NOT count ✗
```
## Web3 Funnel Examples
### Website to On-Chain Conversion
Track the full journey from landing to blockchain:
```
Step 1: page_view (landing page)
Step 2: button_clicked (CTA)
Step 3: wallet_connect
Step 4: swap_initiated (button click)
Step 5: [Transaction] swap on DEX
Filter: utm_source = "twitter"
Window: 7 days
```
### Multi-Chain Attribution
Compare conversion by blockchain:
```
Step 1: wallet_connect
Step 2: chain_selected
Step 3: [Transaction] any transaction
Breakdown: chain
```
### NFT Mint Funnel
Track mint journey:
```
Step 1: collection_viewed
Step 2: wallet_connect
Step 3: mint_initiated
Step 4: [Transaction] mint function
Breakdown: traffic_source
```
### Feature to Transaction
Do feature users convert better?
```
Step 1: feature_used (advanced_charts)
Step 2: [Transaction] any transaction
Compare to:
Step 1: page_view (any page)
Step 2: [Transaction] any transaction
```
## Analyzing Results
### Identifying Drop-Off Points
Look for the biggest drops:
```
├── Step 1 → Step 2: 35% (65% drop) ← Biggest drop!
├── Step 2 → Step 3: 80% (20% drop)
└── Step 3 → Step 4: 90% (10% drop)
Focus on: Why aren't users connecting wallets?
```
### Comparing Segments
Find high-performing segments:
```
By device:
├── Desktop: 12% conversion
└── Mobile: 4% conversion ← Investigate mobile UX
By country:
├── US: 15% conversion
├── UK: 14% conversion
└── DE: 8% conversion ← Different market?
```
### Time Analysis
Understand conversion timing:
```
Users who convert in < 1 hour: 45%
→ Quick decision makers
Users who convert in > 24 hours: 15%
→ Need nurturing/reminders
```
## Best Practices
### Keep Funnels Focused
```
✅ Good: 4-6 steps focused on one journey
page_view → wallet_connect → swap_init → transaction
❌ Avoid: 15 steps covering everything
page_view → click → scroll → hover → click → modal → ...
```
### Choose Appropriate Windows
```
Quick actions (checkout): 1 hour - 1 day
Considered decisions (signup): 1-7 days
Long cycles (enterprise): 7-30 days
```
### Use Consistent Filters
When comparing funnels, use the same base filters:
```
✅ Compare:
- Twitter traffic funnel (filter: utm_source = twitter)
- Discord traffic funnel (filter: utm_source = discord)
❌ Misleading:
- All traffic funnel
- Mobile-only funnel (different population)
```
## Next Steps
Measure user engagement over time
Create user segments
# Insights
Source: https://docs.cryptique.io/analysis/reports/insights
Visualize trends and compositions within your data
## Overview
Insights is a powerful and flexible tool for visualizing trends and compositions in your data. Analyze events, cohorts, user profiles, and transactions with a wide variety of chart types and measurements.
## Use Cases
* How is my WAU (Weekly Active Users) changing over time?
* How often do users swap tokens? (frequency analysis)
* What's the distribution of users across chains? (breakdown)
* How many transactions were made on Ethereum vs Polygon?
* How many unique wallets connected this week?
* What's the total transaction volume by token?
* Which chains have the highest user engagement?
* How has gas spending changed over time?
* Which campaigns drive the most wallet connections?
* What's the conversion rate from Twitter vs Discord traffic?
* How do different referral sources compare in transaction value?
## Quick Start
Select what you want to measure. Click **Add Metric** and choose:
* **Event**: Analyze event occurrences (e.g., `swap_completed`)
* **Transaction**: Analyze on-chain transactions
* **Profile**: Analyze user properties
* **Cohort**: Analyze cohort membership
Decide how to measure:
* **Unique Users**: Count distinct users
* **Total Count**: Count all occurrences
* **Property Sum/Avg**: Aggregate a numeric property
* **Sessions**: Count unique sessions
Narrow your data:
* Filter by event properties
* Filter by user properties
* Filter by transaction properties
Segment your metric:
* By user property (country, plan, etc.)
* By event property (chain, token, etc.)
* By time (day, week, month)
Select the best chart:
* Line chart for trends
* Bar chart for comparisons
* Pie chart for compositions
* Table for detailed data
## Measurements
### Event-Based Measurements
| Measurement | Description | Example |
| -------------------------- | ----------------------------------------- | ---------------------------- |
| **Unique Users** | Count of distinct users who did the event | "How many users swapped?" |
| **Total Count** | Total number of times event occurred | "How many swaps happened?" |
| **Event Property Sum** | Sum of a numeric property | "Total volume swapped (USD)" |
| **Event Property Average** | Average of a numeric property | "Average swap size" |
| **Sessions** | Count of distinct sessions | "Sessions with a swap" |
### Profile-Based Measurements
| Measurement | Description | Example |
| -------------------- | ---------------------------------------- | ---------------------- |
| **Profile Count** | Count of user profiles matching criteria | "Users with pro plan" |
| **Property Sum** | Sum of user profile property | "Total lifetime value" |
| **Property Average** | Average of user profile property | "Average wallet age" |
### Transaction-Based Measurements
| Measurement | Description | Example |
| ------------------------- | ---------------------------------- | ---------------------------- |
| **Unique Wallets** | Count of distinct wallet addresses | "Unique wallets transacting" |
| **Total Transactions** | Count of all transactions | "Total swaps on-chain" |
| **Transaction Value Sum** | Sum of transaction values | "Total ETH swapped" |
| **Gas Sum** | Total gas spent | "Gas used by users" |
## Filters
Filter your data to focus on specific segments:
### Event Filters
```
Events where:
├── event_name = "swap_completed"
├── AND chain = "ethereum"
├── AND amount_usd > 100
└── AND timestamp in last 30 days
```
### User Property Filters
```
Users where:
├── plan = "pro"
├── AND country = "US"
└── AND is_web3_user = true
```
### Transaction Filters
```
Transactions where:
├── contract_name = "Swap Router"
├── AND method_name = "swapExactTokensForTokens"
└── AND status = "confirmed"
```
See [Filters & Operators](/analysis/filters-and-operators) for the complete operator reference.
## Breakdowns
Breakdowns segment your metric by a property value:
### Single Breakdown
```
Total Swaps broken down by Chain:
├── ethereum: 1,234
├── polygon: 892
├── arbitrum: 567
└── base: 445
```
### Multiple Breakdowns
```
Total Swaps by Chain and Token:
├── ethereum
│ ├── ETH: 800
│ ├── USDC: 300
│ └── DAI: 134
├── polygon
│ ├── MATIC: 500
│ └── USDC: 392
└── ...
```
### Breakdown Properties
You can break down by:
* **Event properties**: `chain`, `input_token`, `wallet_type`
* **User properties**: `country`, `plan`, `device_type`
* **Transaction properties**: `method_name`, `contract_name`
* **Time**: Day, week, month
## Visualizations
Cryptique offers 9 chart types to visualize your data:
### Time-Series Charts
For viewing metrics over time:
| Chart | Best For |
| ------------------ | ------------------------------------------------------ |
| **Line** | Trends over time, comparing multiple metrics |
| **Stacked Line** | Composition trends, showing parts of a whole over time |
| **Column** | Discrete time periods, comparing specific days/weeks |
| **Stacked Column** | Composition by time period, part-to-whole by day/week |
### Comparison Charts
For viewing totals and comparisons:
| Chart | Best For |
| --------------- | ---------------------------------------------- |
| **Bar** | Horizontal comparisons, ranking categories |
| **Stacked Bar** | Composition within horizontal categories |
| **Pie** | Part-to-whole relationships, distribution |
| **Cards** | Single headline metrics, KPIs at a glance |
| **Table** | Detailed data, multiple dimensions, drill-down |
## Advanced Features
### Multiple Metrics
Compare multiple metrics in one report:
```
Metric A: Unique users who viewed pool
Metric B: Unique users who added liquidity
Metric C: Unique users who transacted on-chain
→ See conversion through the journey
```
### Formulas
Create calculated metrics:
```
Formula: (Metric B / Metric A) * 100
Where:
- Metric A = Users who connected wallet
- Metric B = Users who transacted
Result: Wallet-to-transaction conversion rate
```
### Time Comparisons
Compare current period to previous:
```
This Week vs Last Week:
├── Swaps: 1,234 (+15%)
├── Unique Users: 567 (+8%)
└── Volume: $1.2M (-3%)
```
### Cohort Comparison
Compare metrics across cohorts:
```
Swap frequency by user type:
├── Whales (>$10k volume): 12.5 swaps/week
├── Active ($1k-$10k): 4.2 swaps/week
└── Casual (<$1k): 1.1 swaps/week
```
## Table Features
When using table visualization:
### Sorting
Click column headers to sort:
* **A-Z**: Alphabetical ascending
* **Z-A**: Alphabetical descending
* **Value ↑**: Lowest to highest
* **Value ↓**: Highest to lowest
### Dynamic Segments
Control how many segments to display:
* Show top 5, 10, 20, or all
* Automatically updates as data changes
### Totals & Subtotals
* **Overall**: Total across all segments
* **Sub-totals**: Totals within each breakdown group
## Web3-Specific Examples
### Transaction Volume by Chain
```
Event: Transaction
Measurement: Sum of value (ETH)
Breakdown: chain
Visualization: Bar chart
Result:
├── ethereum: 1,234 ETH
├── arbitrum: 892 ETH
├── polygon: 567 ETH
└── base: 445 ETH
```
### Wallet Connection Trend
```
Event: wallet_connect
Measurement: Unique users
Time: Last 30 days, daily
Visualization: Line chart
Result: See daily wallet connections trend
```
### Top Tokens by Swap Count
```
Event: swap_completed
Measurement: Total count
Breakdown: output_token
Filter: chain = "ethereum"
Visualization: Horizontal bar
Result: Ranked list of tokens by swap popularity
```
### Cross-Chain User Analysis
```
Event: Transaction
Measurement: Unique wallets
Breakdown: chain
Filter: Users where session_count > 5
Result: Active users per chain
```
## Best Practices
### Start Simple
Begin with one metric and basic filters, then add complexity:
```
1. Total swaps (simple count)
2. + Filter by chain = "ethereum"
3. + Breakdown by token
4. + Compare to last period
```
### Use Meaningful Comparisons
Compare like with like:
```
✅ Good: Compare swap_completed across chains
✅ Good: Compare wallet_connect by utm_source
❌ Misleading: Compare daily vs weekly metrics
❌ Misleading: Compare different time periods without normalizing
```
### Name Your Reports
Save reports with clear names:
```
✅ "Weekly Swap Volume by Chain"
✅ "Twitter Campaign - Wallet Connections"
✅ "Power User Transaction Frequency"
❌ "Report 1"
❌ "Test"
```
## Saving & Sharing
### Save Report
1. Click **Save** after building your report
2. Enter a descriptive name
3. Choose visibility:
* **Personal**: Only you can see
* **Team**: All team members can see
### Add to Board
1. Click **Add to Board**
2. Select existing board or create new
3. Position and resize as needed
Charts in Cryptique are always part of boards. Use boards to organize related visualizations together.
## Next Steps
Measure step-by-step conversions
All filter operators
# Reports Overview
Source: https://docs.cryptique.io/analysis/reports/overview
Understanding Cryptique's report types for Web3 analytics
## Overview
Cryptique provides four powerful report types, each designed to answer different types of questions about your users' behavior—both off-chain and on-chain.
## Report Types
**Visualize trends and compositions**
Answer questions like:
* How many users swapped this week?
* What's the breakdown of users by chain?
* How is retention trending over time?
**Measure conversion through steps**
Answer questions like:
* What % of users who connect a wallet make a transaction?
* Where do users drop off in onboarding?
* How long does it take to convert?
**Measure engagement over time**
Answer questions like:
* How many users return after 7 days?
* What's our weekly transaction retention?
* Are power users more retained?
**See paths users take**
Answer questions like:
* What do users do after connecting a wallet?
* What paths lead to conversion?
* Where do users go after viewing pricing?
## Common Features
All reports share these capabilities:
### Filtering
Narrow your analysis to specific users or events:
```
Show me:
- Users from United States
- Who are on the "pro" plan
- And connected a wallet in the last 30 days
```
### Breakdowns
Segment your data by properties:
```
Break down by:
- Country → See metrics per country
- Device type → Compare mobile vs desktop
- Wallet type → MetaMask vs WalletConnect
```
### Time Controls
Analyze any time period:
* **Date range**: Last 7 days, last 30 days, custom range
* **Granularity**: Hourly, daily, weekly, monthly
* **Comparison**: Compare to previous period
### Cross-Data Analysis
Combine off-chain and on-chain data:
```
Funnel:
1. page_view (website)
2. wallet_connect (website)
3. swap_initiated (website)
4. swapExactTokensForTokens (blockchain transaction)
```
## Choosing the Right Report
| Question Type | Report | Example |
| -------------------------- | --------- | ------------------------------------ |
| "How many?" / "How much?" | Insights | Total swaps this month |
| "What percentage convert?" | Funnels | Conversion rate to first transaction |
| "Do users come back?" | Retention | 7-day retention after signup |
| "What path do users take?" | Flows | Actions after wallet connection |
## Building Reports
### Quick Start
Choose Insights, Funnels, Retention, or Flows
Select the events or transactions to analyze
Unique users, total count, property aggregation
Narrow to specific segments
Segment by properties
Choose chart type and time range
### Example: Cross-Chain Analysis
Analyze user behavior across different blockchains:
1. Create an **Insights** report
2. Select event: `swap_completed`
3. Breakdown by: `chain`
4. Visualization: Stacked bar chart
Result: See swap volume by Ethereum, Polygon, Arbitrum, etc.
### Example: Wallet Connection Funnel
Track the path from landing to on-chain transaction:
1. Create a **Funnels** report
2. Step 1: `page_view` (landing page)
3. Step 2: `wallet_connect`
4. Step 3: `swap_initiated`
5. Step 4: Transaction from "Swap Router" contract
6. Filter by: `utm_source = twitter`
Result: See conversion rate from Twitter traffic to actual swaps.
## Saving & Sharing
### Save Reports
Save frequently-used reports for quick access:
1. Build your report
2. Click **Save**
3. Name your report
4. Choose visibility (personal or team)
### Add to Boards
Combine multiple reports on a dashboard:
1. Open a saved report
2. Click **Add to Board**
3. Select existing board or create new
4. Arrange on the board
See [Boards](/analysis/boards) for more details.
### Share Reports
Share with team members:
1. Save the report
2. Click **Share**
3. Enter email addresses
4. Set permissions (view or edit)
## Next Steps
Visualize trends and metrics
Measure conversion rates
Track user engagement
Understand user paths
# Retention
Source: https://docs.cryptique.io/analysis/reports/retention
Measure how often users return and engage with your product
## Overview
Retention analysis measures how well you keep users engaged over time. Track whether users return after their first visit, first transaction, or any milestone event—and understand what drives long-term engagement.
## Use Cases
* What percentage of new users return after 7 days?
* Is our retention improving over time?
* How does retention compare across user segments?
* Do users continue transacting after their first swap?
* What's the retention curve for NFT collectors?
* Are users on different chains retained differently?
* Do users who use feature X have better retention?
* Does completing onboarding improve retention?
* How does wallet enrichment affect engagement?
## Quick Start
The event that "births" users into the cohort:
```
Birth Event: signup_completed
(or: wallet_connect, first_transaction, etc.)
```
The event that indicates a user "returned":
```
Return Event: any_active_event
(or: transaction, swap_completed, page_view, etc.)
```
Set the cohort interval and retention window:
```
Cohort Interval: Weekly (users grouped by week they were born)
Retention Window: 8 weeks
```
Choose when users count as retained:
* **On or After**: Any time from that day/week onward
* **On**: Only on exactly that day/week
## Retention Criteria
### On or After (Default)
User counts as retained if they returned **on or after** the specified time period:
```
Day 7 retention (On or After):
User returned on Day 7, 8, 9, 10... → Retained ✓
User returned on Day 1-6 only → NOT Retained ✗
```
Best for: Understanding cumulative engagement over time.
### On
User counts as retained only if they returned **exactly on** that period:
```
Day 7 retention (On):
User returned exactly on Day 7 → Retained ✓
User returned on Day 6 or Day 8 → NOT Retained ✗
```
Best for: Understanding precise return patterns.
## Cohort Intervals
Group users by when they were "born":
### Daily Cohorts
```
Daily cohorts over 14 days:
├── Jan 1 cohort: Users born on Jan 1
├── Jan 2 cohort: Users born on Jan 2
├── ...
└── Jan 14 cohort: Users born on Jan 14
See: Day 1, Day 2, ... Day 14 retention for each
```
Best for: Short-term retention analysis, fast-moving products.
### Weekly Cohorts
```
Weekly cohorts over 8 weeks:
├── Week 1 cohort: Users born Jan 1-7
├── Week 2 cohort: Users born Jan 8-14
├── ...
└── Week 8 cohort: Users born Feb 19-25
See: Week 1, Week 2, ... Week 8 retention for each
```
Best for: Most retention analyses, standard timeframe.
### Monthly Cohorts
```
Monthly cohorts over 6 months:
├── January cohort: Users born in January
├── February cohort: Users born in February
├── ...
└── June cohort: Users born in June
See: Month 1, Month 2, ... Month 6 retention for each
```
Best for: Long-term retention, subscription products.
## Custom Brackets
Define custom retention windows:
```
Custom brackets: [1, 3, 7, 14, 30, 60, 90]
View retention at:
├── Day 1
├── Day 3
├── Day 7
├── Day 14
├── Day 30
├── Day 60
└── Day 90
```
## Reading the Retention Table
```
│ Day 0 │ Day 1 │ Day 7 │ Day 14 │ Day 30
───────────┼───────┼───────┼───────┼────────┼────────
Jan 1-7 │ 1,000 │ 42% │ 28% │ 22% │ 15%
Jan 8-14 │ 850 │ 45% │ 30% │ 24% │ 18%
Jan 15-21 │ 1,200 │ 38% │ 25% │ 20% │ -
Jan 22-28 │ 950 │ 40% │ 27% │ - │ -
───────────┼───────┼───────┼───────┼────────┼────────
Average │ 1,000 │ 41% │ 28% │ 22% │ 17%
```
**Column meanings:**
* **Day 0**: Number of users in cohort (birth event count)
* **Day N**: Percentage who returned on/after day N
**Row meanings:**
* Each row is a cohort (users born in that period)
* Newer cohorts have fewer data points (diagonal empty)
## Retention Curves
### Visualizing Retention
```
100% ─┬────────────────────────
│\
│ \
50% ─┤ \___
│ \_____
│ \________
0% ─┴─────────────────────────
Day 0 7 14 21 28 35
```
**Healthy retention**: Curve flattens (users who stay, stay)
**Concerning retention**: Curve keeps declining (ongoing churn)
### Comparing Curves
```
100% ─┬────────────────────────
│\
│ \__ Pro users
│ \_______________
50% ─┤
│ \
│ \___ Free users
│ \______
0% ─┴─────────────────────────
```
## Filters
Focus on specific user segments:
### Birth Event Filters
Filter who enters the cohort:
```
Birth Event: signup_completed
└── where: signup_source = "twitter"
Only users who signed up from Twitter
```
### Return Event Filters
Filter what counts as "returning":
```
Return Event: transaction
└── where: chain = "ethereum"
Users must transact on Ethereum to count as retained
```
### User Property Filters
Filter by user attributes:
```
User Filter:
├── plan = "pro"
├── AND country = "US"
Retention for US Pro users only
```
## Breakdowns
Compare retention across segments:
### By User Property
```
Retention by plan:
├── Pro: 45% → 32% → 28%
├── Free: 38% → 22% → 15%
└── Trial: 25% → 12% → 8%
```
### By Birth Event Property
```
Retention by signup_source:
├── Twitter: 40% → 28% → 22%
├── Discord: 52% → 38% → 32%
└── Google: 35% → 20% → 14%
```
### By Cohort Date
Default view—compare how retention changes over time:
```
Are newer cohorts retaining better?
├── Jan cohorts: 40% → 25% → 18%
├── Feb cohorts: 42% → 28% → 22%
└── Mar cohorts: 45% → 32% → 25%
→ Yes! Retention is improving
```
## Web3 Retention Examples
### Transaction Retention
Track on-chain engagement:
```
Birth Event: First transaction
Return Event: Any transaction
Question: Do users keep transacting?
```
### Protocol Stickiness
```
Birth Event: First swap
Return Event: swap_completed
Filter by: chain = "arbitrum"
Question: Do Arbitrum users keep swapping?
```
### NFT Collector Retention
```
Birth Event: First NFT mint
Return Event: Any NFT activity (mint, transfer, sale)
Question: Do minters become collectors?
```
### Feature-Driven Retention
```
Birth Event: used_advanced_feature
Return Event: any_active_event
Compare to:
Birth Event: did_not_use_advanced_feature
Return Event: any_active_event
Question: Does the feature improve retention?
```
## Analyzing Retention
### Key Metrics
| Metric | Description | Good Benchmark |
| ----------- | -------------------------- | -------------- |
| **Day 1** | Next-day return | >40% |
| **Day 7** | Week 1 return | >25% |
| **Day 30** | Month 1 return | >15% |
| **Plateau** | Stable long-term retention | >10% |
### Signs of Healthy Retention
```
✅ Curve flattens (stabilizes)
✅ Newer cohorts retain better
✅ Power users have much higher retention
✅ Key features correlate with retention
```
### Warning Signs
```
❌ Curve never flattens (constant churn)
❌ Newer cohorts performing worse
❌ No difference between segments
❌ Day 1 retention below 30%
```
## Best Practices
### Choose Meaningful Events
```
✅ Good birth events:
- signup_completed (clear milestone)
- wallet_connect (clear commitment)
- first_transaction (value delivered)
❌ Poor birth events:
- page_view (too broad)
- click (too minor)
```
### Match Return to Product
```
Social app: Return = any_active_event
DeFi protocol: Return = transaction
Marketplace: Return = purchase OR listing
SaaS: Return = feature_used
```
### Segment Meaningfully
Compare segments that inform action:
```
✅ Actionable:
- By signup_source (optimize marketing)
- By completed_onboarding (improve onboarding)
- By user_tier (price/feature adjustments)
❌ Not actionable:
- By random_id
- By timestamp
```
### Allow Enough Time
Retention analysis needs mature data:
```
For Day 30 retention with weekly cohorts:
Need 5-6 weeks of data minimum
For quarterly analysis:
Need 6+ months of data
```
## Saving & Sharing
### Save Report
1. Configure your retention analysis
2. Click **Save**
3. Name it: "Weekly Transaction Retention by Chain"
### Add to Board
1. Save the report
2. Click **Add to Board**
3. Select dashboard
All reports are added to boards for organization and sharing.
## Next Steps
Understand user paths
Create user segments
# Time Controls
Source: https://docs.cryptique.io/analysis/time-controls
Configure time ranges and granularity for your reports
## Overview
Time controls let you define what time period to analyze and at what granularity to view the data. Every report in Cryptique supports flexible time configuration.
## Time Range Selection
### Preset Ranges
Quick selection for common time periods:
| Preset | Description |
| ----------------- | ----------------------------- |
| **Today** | Current day (midnight to now) |
| **Yesterday** | Previous full day |
| **Last 7 days** | Past week including today |
| **Last 14 days** | Past two weeks |
| **Last 30 days** | Past month |
| **Last 90 days** | Past quarter |
| **Last 365 days** | Past year |
| **This week** | Current week (Monday to now) |
| **This month** | Current month (1st to now) |
| **This quarter** | Current quarter |
| **This year** | Current year (Jan 1 to now) |
### Custom Date Range
Select specific start and end dates:
```
Custom Range:
├── Start: January 1, 2024
└── End: January 31, 2024
Include: All events from Jan 1 00:00 to Jan 31 23:59
```
### Rolling Windows
Automatically update to show the most recent data:
```
Rolling 30 days:
├── Always shows the last 30 days
├── Updates automatically each day
└── Great for dashboards
```
## Granularity
Granularity controls how data is grouped in time-series views:
| Granularity | Best For |
| ------------- | ---------------------------------------- |
| **Hourly** | Intraday patterns, short-term analysis |
| **Daily** | Day-over-day trends, standard analysis |
| **Weekly** | Week-over-week patterns, smoothing noise |
| **Monthly** | Long-term trends, executive reporting |
| **Quarterly** | Business planning, strategic analysis |
### Matching Granularity to Range
```
✅ Good combinations:
├── Last 24 hours → Hourly granularity
├── Last 7 days → Daily granularity
├── Last 30 days → Daily or weekly
├── Last 90 days → Weekly granularity
├── Last 365 days → Monthly granularity
❌ Poor combinations:
├── Last 365 days → Hourly (too many data points)
├── Last 24 hours → Monthly (not enough data)
```
## Time Comparisons
Compare current period to previous periods:
### Previous Period
Compare to the immediately preceding period:
```
Last 7 days vs Previous 7 days:
├── Current: 1,234 swaps
├── Previous: 1,100 swaps
└── Change: +12.2%
```
### Same Period Last Year
Compare to the same period one year ago:
```
January 2024 vs January 2023:
├── Current: 45,000 users
├── Last year: 28,000 users
└── Change: +60.7% YoY
```
### Custom Comparison
Compare any two time periods:
```
Compare:
├── Period A: Dec 1-31, 2023 (holiday season)
├── Period B: Nov 1-30, 2023 (pre-holiday)
└── See: Holiday impact on metrics
```
## Session Timing
Cryptique uses a **30-minute session timeout** (not configurable):
```
Session Definition:
├── Session starts: First event from user
├── Session continues: Events within 30 min of last event
├── Session ends: 30 min of inactivity
└── New session: Activity after 30 min gap
```
### Session Examples
```
User Activity Timeline:
├── 10:00 - page_view (Session 1 starts)
├── 10:05 - button_click (Session 1 continues)
├── 10:15 - swap_completed (Session 1 continues)
├── 10:45 - (30 min idle)
├── 11:00 - page_view (Session 2 starts)
└── 11:30 - session ends
Result: 2 sessions
```
## Time-Based Filtering
Filter events by time properties:
### Event Timestamp
```
Filter: timestamp last 30 days
Filter: timestamp between "2024-01-01" and "2024-01-31"
Filter: timestamp since "2024-01-01"
```
### User First Seen
```
Filter: first_seen last 7 days
→ Only new users from this week
```
### User Last Seen
```
Filter: last_seen before_the_last 30 days
→ Users who haven't been active in a month
```
See [Filters & Operators](/analysis/filters-and-operators) for complete datetime operators.
## Timezone Handling
Cryptique automatically captures user timezone:
```
Default Property: timezone
Example values: "America/New_York", "Europe/London", "Asia/Tokyo"
```
### Dashboard Timezone
Reports display in your selected timezone:
1. Go to **Settings**
2. Select your timezone
3. All reports adjust accordingly
### UTC Storage
All timestamps are stored in UTC internally:
* Consistent data across timezones
* No daylight saving issues
* Accurate global comparisons
## Time Patterns
### Day of Week Analysis
Breakdown by day to see weekly patterns:
```
Swaps by day of week:
├── Monday: 15%
├── Tuesday: 16%
├── Wednesday: 17%
├── Thursday: 16%
├── Friday: 18%
├── Saturday: 10%
└── Sunday: 8%
Insight: Weekday trading dominates
```
### Hour of Day Analysis
Breakdown by hour for daily patterns:
```
Swaps by hour (UTC):
├── 00-04: Low activity
├── 04-08: Rising (Asia)
├── 08-12: Peak (Europe)
├── 12-16: High (US East opens)
├── 16-20: Peak (US full)
└── 20-00: Declining
Insight: Schedule campaigns for peak hours
```
### Monthly Trends
See seasonality:
```
Monthly active users:
├── Jan: 45K
├── Feb: 48K
├── Mar: 52K
├── Apr: 58K
├── May: 55K
├── Jun: 50K
├── Jul: 48K
├── Aug: 51K
├── Sep: 60K
├── Oct: 65K
├── Nov: 70K
└── Dec: 62K
Insight: Q4 is your peak season
```
## Web3 Time Considerations
### Block Time vs Event Time
Cryptique tracks both:
* **Event time**: When user initiated action
* **Transaction time**: When block was mined
```
User clicks "Swap" at 10:00:00 (event_time)
Transaction confirms at 10:00:45 (block_time)
Events use event_time
Transactions use block_time
```
### Chain-Specific Timing
Different blockchains have different block times:
| Chain | Avg Block Time |
| -------- | -------------- |
| Ethereum | \~12 seconds |
| Polygon | \~2 seconds |
| Arbitrum | \~0.25 seconds |
| Base | \~2 seconds |
For time-sensitive analysis, consider block confirmations.
## Dashboard Time Controls
### Global Time Selector
Dashboards can have a global time selector:
```
Dashboard: Weekly Overview
Global Time: Last 7 days
All charts on dashboard use "Last 7 days"
Override individual charts if needed
```
### Per-Chart Time
Override global time for specific charts:
```
Dashboard Time: Last 7 days
Chart 1: Uses dashboard time (7 days)
Chart 2: Uses dashboard time (7 days)
Chart 3: Custom time (Last 30 days) ← Override
```
## Best Practices
### Match Time to Question
```
Question: What happened today?
Time: Today, hourly granularity
Question: How are we trending this month?
Time: Last 30 days, daily granularity
Question: Year-over-year growth?
Time: Last 365 days, monthly granularity
```
### Use Comparisons Wisely
```
✅ Good comparisons:
├── Week-over-week (similar periods)
├── Month-over-month (business rhythm)
├── Year-over-year (seasonal adjustment)
❌ Poor comparisons:
├── Monday vs Sunday (different behavior)
├── Holiday vs normal week (outliers)
├── Launch week vs normal (unusual activity)
```
### Account for Data Lag
Recent data may be incomplete:
```
If analyzing "Today":
├── Events appear in real-time
├── Transactions may have confirmation lag
├── Some aggregations update hourly
Recommendation: Use "Yesterday" for complete daily data
```
### Smooth Volatility
Use longer time ranges or weekly granularity to smooth noise:
```
Daily view: Volatile, hard to see trend
Weekly view: Smoother, clear trend visible
```
## Next Steps
Learn about report types
Create dashboards
# Users
Source: https://docs.cryptique.io/analysis/users
Explore individual user profiles and activity timelines
## Overview
The Users section lets you explore individual user profiles, view complete activity timelines, and understand the full journey of any user—from their first page view to their most recent transaction.
## Finding Users
### Search Methods
Find users by any identifier:
| Search By | Example | Description |
| ------------------- | ---------------------- | ----------------------- |
| **distinct\_id** | `user_12345` | Primary user identifier |
| **wallet\_address** | `0x1234...abcd` | Any connected wallet |
| **email** | `user@example.com` | If set via identify() |
| **Custom property** | `username: defi_whale` | Any user property |
### Search Interface
```
┌─────────────────────────────────────────────────┐
│ Search users... 🔍 │
├─────────────────────────────────────────────────┤
│ │
│ Recent Users: │
│ ├── user_12345 (2 mins ago) │
│ ├── 0x1234...abcd (5 mins ago) │
│ └── anon_xyz789 (10 mins ago) │
│ │
│ Active Users: 1,234 in last hour │
│ │
└─────────────────────────────────────────────────┘
```
## User Profile View
### Profile Header
```
┌─────────────────────────────────────────────────┐
│ user_12345 │
│ john@example.com │
│ │
│ First seen: Jan 1, 2024 │
│ Last seen: 5 minutes ago │
│ Sessions: 47 │
│ Events: 1,250 │
│ │
│ Wallets: │
│ ├── 0x1234...abcd (primary) │
│ └── 0xdef0...5678 │
└─────────────────────────────────────────────────┘
```
### User Properties
View all properties set on the user:
```
Properties:
├── Identity
│ ├── email: john@example.com
│ ├── username: defi_whale
│ └── name: John Doe
│
├── Custom
│ ├── plan: pro
│ ├── referral_source: twitter
│ └── onboarding_completed: true
│
├── Web3
│ ├── is_web3_user: true
│ ├── primary_wallet: 0x1234...
│ ├── wallet_age_days: 847
│ └── total_transactions: 523
│
└── Lifecycle
├── first_seen: 2024-01-01
├── last_seen: 2024-02-15
└── session_count: 47
```
### Enriched Properties
If wallet enrichment is enabled:
```
Wallet Enrichment (0x1234...):
├── wallet_age_days: 847
├── eth_balance: 15.5
├── total_transaction_count: 523
├── nft_count: 42
├── defi_protocols: ["uniswap", "aave", "compound"]
└── is_whale: true
```
## Activity Timeline
The timeline shows every event for this user in chronological order:
```
Timeline for user_12345
───────────────────────────────────────────────────
Today, 2:30 PM
├── swap_completed
│ ├── input_token: ETH
│ ├── output_token: USDC
│ └── amount: 1.5
Today, 2:29 PM
├── [Transaction] Swap Router
│ ├── method: swapExactTokensForTokens
│ ├── hash: 0xabc123...
│ └── chain: ethereum
Today, 2:28 PM
├── swap_initiated
│ └── input_token: ETH
Today, 2:25 PM
├── page_view
│ └── uri: /swap
───────────────────────────────────────────────────
Yesterday, 4:15 PM
├── wallet_connect
│ ├── wallet_address: 0x1234...
│ └── wallet_type: metamask
Yesterday, 4:10 PM
├── page_view
│ ├── uri: /
│ └── referrer: twitter.com
───────────────────────────────────────────────────
```
### Timeline Features
* **Expandable events**: Click to see all properties
* **Time grouping**: Events grouped by day/session
* **Event filtering**: Filter to specific event types
* **Transaction highlighting**: On-chain transactions marked
* **Infinite scroll**: Load more historical events
### Filtering Timeline
Filter to specific event types:
```
Show: [All Events ▼]
├── All Events
├── Custom Events Only
├── Auto Events Only
├── Transactions Only
├── Wallet Events Only
└── Specific Event: [search]
```
## Linked Data
User profiles provide **full attribution** by linking multiple data sources:
* **Events** are linked to users via `distinct_id`
* **Transactions** are linked to users via `wallet_address`
This means when a user connects their wallet, all their on-chain activity becomes attributed to their user profile, creating a complete picture from first website visit to blockchain transactions.
### Connected Wallets
View all wallets linked to this user:
```
Wallets (2):
┌──────────────────────────────────────────────┐
│ 0x1234...abcd │
│ ├── Connected: Jan 2, 2024 │
│ ├── Transactions: 45 │
│ ├── Primary: Yes │
│ └── Chains: ethereum, polygon, arbitrum │
├──────────────────────────────────────────────┤
│ 0xdef0...5678 │
│ ├── Connected: Feb 1, 2024 │
│ ├── Transactions: 12 │
│ ├── Primary: No │
│ └── Chains: ethereum │
└──────────────────────────────────────────────┘
```
### Transactions
View all on-chain transactions:
```
Transactions (57):
├── Feb 15, 2:29 PM │ Swap Router │ swap │ 0xabc...
├── Feb 15, 10:15 AM │ Swap Router │ swap │ 0xdef...
├── Feb 14, 3:45 PM │ NFT Contract │ mint │ 0x123...
├── Feb 13, 11:20 AM │ Staking │ stake │ 0x456...
└── ... (load more)
```
### Sessions
View session history:
```
Sessions (47):
├── Today, 2:25 PM - 2:35 PM (10 min, 8 events)
├── Yesterday, 4:10 PM - 4:45 PM (35 min, 23 events)
├── Feb 13, 9:00 AM - 9:30 AM (30 min, 15 events)
└── ... (load more)
```
## User Actions
### From Profile Page
Take actions on a user:
```
Actions:
├── View in Cohorts → See which cohorts include this user
├── Create Cohort → Start a cohort with this user's properties
├── Export → Download user data as JSON
└── Delete Profile → Remove user profile (with confirmation)
```
### Add to Cohort
Create cohort based on this user's properties:
```
Create cohort like user_12345:
├── plan = "pro"
├── country = "US"
└── is_web3_user = true
→ Find all users matching these criteria
```
## Use Cases
### Debugging User Issues
When a user reports a problem:
1. Search by email or wallet
2. View their recent timeline
3. Look for errors or unexpected events
4. Check transaction status
### Understanding Power Users
Analyze your best users:
1. Search by known power user ID
2. Study their event sequence
3. Note feature usage patterns
4. Create cohort of similar users
### Support Investigation
Customer support workflow:
1. User provides wallet address
2. Search to find profile
3. View recent activity
4. Identify issues or patterns
### Attribution Verification
Verify marketing attribution:
1. Find user who transacted
2. Check initial\_referrer
3. Verify UTM parameters
4. Confirm attribution accuracy
## Privacy & Access
### Who Can View Users
* **Admins**: Full access to all users
* **Users**: Can view users (configurable)
* **Public**: No access
### Sensitive Data
Some properties may be redacted:
```
Properties:
├── email: john@example.com ← Visible to admins
├── plan: pro
└── ssn: [REDACTED] ← Never stored (if attempted)
```
### Audit Logging
User profile access is logged:
```
Audit Log:
├── Admin A viewed user_12345 at 2:30 PM
├── Admin B exported user_12345 at 2:45 PM
└── ...
```
## Next Steps
Group users into segments
Learn about profile data
# Changelog
Source: https://docs.cryptique.io/changelog/overview
Latest updates and releases
## Overview
Stay up to date with Cryptique releases, new features, and improvements.
Subscribe to our changelog to get notified of new releases. Email [hello@cryptique.io](mailto:hello@cryptique.io) to join the mailing list.
***
## March 2026
### Week of Mar 24–30
* New [Groups](/data-in/sdk-reference/groups) SDK reference: `set_group`, `add_group`, `remove_group`, `get_group`, event enrichment, and `identify()` hydration.
* [Auto-Events](/data-in/auto-events) rewritten to match the current SDK: enable/disable defaults, full event name catalog, JavaScript API, SPA path handling, and notes on `page_summary`, errors, and performance events.
* Cross-links and corrections across Installation, Quickstart, Glossary, Data Model, Events & Properties, Default Properties, User Profiles, Identify, People, Implementation Guide, Privacy, and GTM (including real auto-event names such as `element_click` and `copy_action`).
### Week of Mar 16–22
* **15 auto-captured events** (expanded from 8), organized into categories: navigation, interaction, visibility, form, media, error, and performance.
* **New interaction events**: `rage_click` (3+ clicks on same element in 1s), `dead_click` (click on non-interactive element with no navigation), `text_selection` (≥3 chars selected), `element_view` (element ≥50% visible for ≥1s via IntersectionObserver).
* **New form events**: `form_validation_error` (HTML5 `invalid` event on a field), `form_abandoned` (page unload with form touched but not submitted; sent via `sendBeacon`).
* **New media events**: `media_play` and `media_pause` for `
***
## February 2026
### Week of Feb 1–7
* Column set: Smart contract (chain), Function name, Transaction time, Tx hash, Block, From, To, Value.
* Required columns (contract, function, time) always on; rest toggleable and reorderable.
* Column config modal: checkboxes and drag-and-drop; selection persisted with table preferences.
* Categories (e.g. core, blockchain, addresses) for easier grouping in the modal.
### Week of Feb 8–14
* Dedicated transaction row component: consistent formatting, truncation for long hashes/addresses, copy-to-clipboard.
* Transaction detail view: full hash, block, from/to, value, input data snippet, status, gas (when available).
* Properties tab: all known fields (contract, function, args, chain, timestamp) in a structured layout.
* Link to block explorer (chain-specific) when chain and hash are known.
### Week of Feb 15–21
* Filter bar for transactions: by contract (multi-select), time range, optional wallet or hash search.
* Filter state synced with URL or local state so "filtered view" is shareable or restorable.
* Combined with events and sessions filters so "events in range → sessions → transactions" flows feel consistent.
* Clear filters and "no results" state with suggestion to widen criteria.
### Week of Feb 22–28
* Filter by cohorts in Analytics using global filters; events are limited to users in the selected cohorts (multiple cohorts use "or" — user in any of them).
* Break down charts by Cohort, same as by Country or Device; choosing "Cohort" segments data by all your cohorts without picking them one by one.
* Cohort filters appear as a single chip with the cohort name and can be edited or removed from the filter bar.
* List-type user properties (e.g. roles, tags) support "Any in list" and "All in list" with the right operators and value pickers.
* Object-type properties (e.g. profile) let you pick a nested field (e.g. role, plan) in the same screen, with data type shown and no extra popup.
* Custom user property filters can use suggested values from your data where available.
* List and object handling in Cohorts and Users filters now matches Activity → Events.
* Sessions page: list of sessions with duration, page views, first/last event, device, country.
* Session row: expand or click-through to session detail (timeline of pages and events).
* Alignment with events and transactions: same table styling, loading states, and empty states.
* Optional session-level filters (e.g. min duration, has event key) for funnel analysis.
* On-chain transactions table uses the same column config and filter module as the main Activity view.
* Transaction detail modal available from both Activity and any embedded transaction list.
* Team and contract scoping: only transactions for the team's registered contracts appear; no cross-team leakage.
* Shared data table styles: borders, density, hover, and focus for accessibility.
* Skeleton loaders and incremental load for large event/session/transaction lists.
* Error boundaries and inline error messages so one failed section doesn't break the whole page.
* Backend: transaction list API supports filter params and returns contract name and chain; response shape stable for the new UI.
***
## January 2026
### Week of Jan 1–7
* Filters (date, device, country, Web3 status, wallet net worth, etc.) apply only to the user list and to aggregate metrics.
* User detail, timeline, dapps, and tokens APIs ignore filters and return full history for the selected user.
* Documented contract: "filter to find users; then inspect anyone in full."
* Metrics (unique users, geography, devices, activity charts) respect current filter set.
### Week of Jan 8–14
* Dedicated pipeline: Blockscout API for Soneium balance and token list; DexScreener for USD prices.
* Native SONE + ERC-20 token balances; aggregated USD per wallet and stored in wallet\_networth.soneium.
* Rate limiting and retries (exponential backoff + jitter); timeouts to avoid hanging.
* On failure: return 0 or last-known value; never fail the whole aggregation.
* Central chain config: chain ID, name, API provider (Etherscan-compatible, Blockscout, etc.), transaction caps, block chunk size, and API offset limits.
* Dozens of networks supported (Ethereum, Base, Arbitrum, Polygon, Optimism, BNB, Avalanche, Soneium, Berachain, etc.).
* Per-chain transaction fetcher tuning so we stay within provider limits and avoid bans.
### Week of Jan 15–21
* Dedicated Events view: list of events with key, count, last seen; filters by key, time, property.
* Sessions view: session list with duration, page views, device, location; link to event list for that session.
* Activity view: on-chain transactions for the team's contracts; table with hash, block, from/to, value, time, function.
* Shared filter bar and filter modules (dropdowns, date range, multi-select) across events/sessions/activity.
* Event detail: payload, related sessions/users; session detail: pages, events, and linked identity.
### Week of Jan 22–31
* User preferences API and client state for table column visibility and order.
* Preferences keyed by team and optional user; defaults for new users.
* Conversion events tables (events, sessions, transactions) respect saved column sets.
* Last-used time range and filters considered for "restore previous session" (where implemented).
* Transaction list: sort by time, filter by contract, time range, wallet (future).
* Display of contract name + chain; function name from decoded input where ABI is present.
* Value formatting (wei → human-readable; optional USD if price pipeline exists).
* Pagination and "load more" with stable ordering (transaction\_time, id).
***
## December 2025
### Week of Dec 1–7
* Identify API: attach email, name, phone, and custom traits to user\_id; stored on user\_identities.
* distinct\_id: optional stable cross-device ID; added to user\_identities, sessions, events, and UTM event logs.
* Merge logic: same user\_id with different distinct\_id can be linked for analytics.
* Downstream: event ingestion can accept distinct\_id; resolution to user\_id where configured.
### Week of Dec 8–14
* website\_ids array on user\_identities for users touching multiple properties.
* Queries can scope by single website or "any of these websites".
* Cross-website user view (optional) for teams that need cross-property journey.
* Custom key-value on user\_identities with validation (key format, value type).
* Property discovery: indexes and metadata for "which custom properties exist" per team/website.
* Filters in user list and dashboards can use custom properties (e.g. plan\_type, signup\_source).
### Week of Dec 15–21
* Datetime columns converted to arrays where one UTM row represents multiple hits over time.
* Queries updated for array semantics; no loss of granularity.
* Migration script with validation and rollback path.
* Team-level table preferences: which columns to show, order, default sort for main tables.
* Stored per team and optional per user; UI reads preference and applies on load.
* Applied to user list, events list, sessions list (where applicable).
### Week of Dec 22–31
* Subscription-protected routes check team plan and status before serving.
* Grace period for expired subscriptions (e.g. 7 days) with warning in UI.
* Stripe Customer Portal link for self-service plan change and billing history.
* Client-side subscription context so UI can show upgrade prompts or feature gates.
* Structured logging with request ID and team\_id for tracing.
* Error classification (4xx vs 5xx) and safe error messages (no internal paths).
* Health endpoint extended with DB and optional cache checks.
***
## October 2025
### Week of Oct 1–7
* Contract entity: address, optional ABI, chain ID, and display name per team.
* Only contracts registered for a team are used for transaction matching.
* Support for multiple chains per team; contract list API with pagination and filters.
* Transaction fetcher worker: block-range polling with configurable chunk size (e.g. 100k blocks).
* Per-chain API limits and backoff (e.g. Etherscan 10k results per request); rate limiting and jitter.
* Stored fields: tx hash, block number, from/to, value, timestamp, contract\_id, team\_id.
* Incremental append; duplicate hashes ignored for idempotency.
### Week of Oct 8–14
* Unified identity: one row per (user\_id, team\_id, website\_id) with composite unique constraint.
* First/last visit, total page views, total time spent; first/last country and city.
* Device type, browser, OS from user-agent parsing (mobile/tablet/desktop).
* Optional Web3 fields: primary\_wallet\_address, other\_wallets, wallet\_type, chain.
* Every session create/update triggers identity upsert: new identity or merge into existing.
* Session IDs array on identity for “all sessions for this user”; no duplicate sessions.
* Migration of legacy session data into user\_identities with preserved timestamps.
### Week of Oct 15–21
* Rule: link transaction to identity only if wallet matches identity’s primary or other\_wallets (canonical lowercase).
* Contract must belong to the same team; team\_id enforced on both transactions and identities.
* contract\_transaction\_ids array on identity; aligned to\_value and from\_value arrays (same length).
* Direction: to\_address match → append to to\_value; from\_address match → append to from\_value.
* Internal transfers (same user to self): two entries appended (in and out) for correct totals.
* to\_value/from\_value as JSONB arrays; GIN indexes for “has transaction in range” queries.
* Full recompute: by team contracts → identities with wallets → transactions → match and overwrite arrays.
* Incremental: on transaction batch insert, fetch new txs, resolve contract and identities, append only.
* Array length invariant: len(contract\_transaction\_ids) == len(to\_value) == len(from\_value) enforced on write.
### Week of Oct 22–31
* wallet\_networth schema: per-chain or per-asset breakdown; migration from legacy single-value format.
* Backward-compatible reads during migration; old clients still receive a valid structure.
* Dashboard entity: name, layout (grid), saved query references, and visibility (private/team).
* Row-level security so users only see dashboards they own or are shared with.
* Query execution with parameter binding and timeout; results cached for repeat views.
* User-agent → device\_type (mobile/tablet/desktop) with fallback to “unknown”.
* Stored on session and rolled up to user identity for segment filters.
***
## November 2025
### Week of Nov 1–7
* Shareable read-only link with optional expiry; no login required.
* Dedicated read-only DB role for public dashboard queries; no write or schema access.
* Token or slug in URL; rate limiting per link to prevent abuse.
* Billing record per team for active Stripe subscription; plan ID, status, current period.
* Webhook handler for subscription created/updated/canceled/deleted; idempotent and verified with signing secret.
* No billing rows for free teams; Stripe as source of truth for paid state.
* Usage tracked separately (events, API calls) for future metering.
### Week of Nov 8–14
* New events schema with integer primary keys; raw\_event\_logs stores integer session\_ids and user\_ids.
* Ingestion: client sends external UUIDs; backend resolves to internal PKs and stores PKs only.
* Resolution strict: missing session or user → 4xx and event not stored.
* Event definition details API: joins back to sessions/user\_identities to return external UUIDs in responses so client contract unchanged.
### Week of Nov 15–21
* User timeline API: events filtered by external user\_id via join on user\_identities (internal PK in raw\_event\_logs).
* Stats/aggregates: distinct user counts use INTEGER casting on JSONB array elements and null-safe logic.
* Composite index on (team\_id, website\_id, event\_key, time) for event drill-downs.
* Deprecation of old custom-events tables; one events pipeline and one schema.
* Team usage ledger: debits for events, API calls, etc.; credits for plan allowances or top-ups.
* Credit operations table for audit trail (grant, consume, expire).
* Billing logic migrated to ledger + operations; subscription downgrade applies to future periods only.
### Week of Nov 22–30
* PostgreSQL 16 + TimescaleDB: hypertables for time-series (sessions, events); standard tables for relational data.
* JSONB for flexible event payloads and wallet\_networth; GIN where needed.
* Documented scalability path: single DB → read replicas → optional event streaming.
* Backup and retention policy documented; point-in-time recovery options.
* API operations table for per-team, per-endpoint call counts.
* Preparation for rate limits and plan-based caps (not yet enforced in product).
***
## September 2025
### Week of Sep 2–8
* Email/password signup and login with secure token refresh.
* JWT-based sessions with configurable expiry; refresh flow without re-login.
* Team-scoped multi-tenancy: all data isolated by team; team members and roles supported.
* Website entity: multiple trackable properties per team with separate config and keys.
* First-party session creation and updates via tracking API.
* Persisted fields: first/last visit, page view count, referrer, and geo (country/city).
* Server-side idempotency for duplicate requests; session continuity across tabs.
### Week of Sep 9–15
* Campaign definitions with UTM parameter sets (source, medium, campaign, term, content).
* UTM event log: one row per UTM combination with aggregated counts and timestamps.
* Cascade rules: campaign changes propagate to UTM aggregates; no orphaned UTM rows.
* Indexes on (team\_id, website\_id, utm\_) for fast campaign drill-downs.
* Event ingestion accepting event key, optional payload, and session/user references.
* Event keys validated and normalized; invalid keys rejected with clear errors.
* Batch endpoint for up to 500 events per request; non-blocking processing.
### Week of Sep 16–22
* Raw event log with JSONB payload; schema-on-read for arbitrary properties.
* Event key uniqueness and case handling; migration to fix legacy missing keys.
* Permissions aligned with team/website; RLS-style checks for event read/write.
* UTM event log restructured to one row per UTM identity for accurate attribution.
* No more double-counting when the same UTM appears in multiple sessions.
* Backfill script for existing data; zero-downtime migration window.
### Week of Sep 23–30
* Campaign definition updates trigger UTM log invalidation/rebuild where needed.
* UTM removal from a campaign correctly prunes or marks affected UTM rows.
* Documentation of campaign → UTM dependency graph for support and ops.
* Connection pooling and query timeouts to avoid long-running requests.
* Retry policy for transient DB errors on event and session writes.
* Health check endpoint for load balancers and monitoring.
***
## Feedback
Have feature requests or found a bug? Let us know:
* **Email**: [hello@cryptique.io](mailto:hello@cryptique.io)
* **Support**: [Live Chat](https://tawk.to/chat/697c9c380c73c21c37c52292/1jg7c4fos)
***
Start using Cryptique
View all methods
# Auto-Events
Source: https://docs.cryptique.io/data-in/auto-events
Events automatically captured by Cryptique without additional code
## Overview
When `auto-events` is enabled, Cryptique automatically captures user interactions without requiring any additional code. This provides comprehensive behavioral data out of the box.
## Automatic Events
| Event | Category | Fires When | Throttle |
| ----------------------- | ----------- | ----------------------------------------------------- | ---------------------------- |
| `page_view` | navigation | DOM ready | Once per load |
| `element_click` | interaction | Any click | None |
| `rage_click` | interaction | 3+ clicks on same element in 1s | 1s detection window |
| `dead_click` | interaction | Click on non-interactive element, no navigation in 1s | 1s post-click delay |
| `page_scroll` | interaction | New max scroll depth reached | 250ms debounce |
| `text_selection` | interaction | ≥3 chars selected, different from last selection | 300ms debounce + 1s cooldown |
| `element_view` | visibility | Element ≥50% visible for ≥1s | Once per element per load |
| `form_submit` | form | HTML form submits | None |
| `form_validation_error` | form | HTML5 `invalid` event on a field | None |
| `form_abandoned` | form | Page unloads with form touched but not submitted | On `beforeunload` |
| `media_play` | media | `