Written by Charbel Habchy • Published November 17 2025

For the last ~1.5 months I have been working with the OnlyLinks team on something I have wanted for a long time:

Turn OnlyLinks from a boring, gray, CRM looking tool into a product that actually feels alive.

Same core idea. Completely new UI and UX.

The funny part is that v1 did not come from a bad place. It was the classic move: ship something fast, prove it works, keep adding features. Over time we ended up with a product that functioned well, but visually felt like every other dashboard on the internet.

v2 is where we finally paused, zoomed out, and rebuilt the experience to match what OnlyLinks actually is.

What Was Wrong With v1

v1 did its job, but visually it had a few big problems:

• It looked like a generic admin dashboard template
• Lots of flat gray and white surfaces
• Thin borders and basic cards that all felt the same
• Navigation that felt very "tool list", not a real system

If you squinted, you could swap the logo and it might as well be any random CRM.

There was also a subtle issue: the interface was not telling you what mattered. Metrics, tables, and buttons all sat on the same visual level. You could accomplish tasks, but the UI was not guiding you emotionally or visually.

Creators and teams are building their brands in OnlyLinks. The product did not feel like it belonged in that world yet.

Design Goals For v2

When we started the redesign, we set a few simple goals that we kept coming back to in every review:

1. Make OnlyLinks feel like a brand, not a template
   Color, gradients, and motion should be baked into the core language, not just dropped on top at the end.

2. Build one consistent design system
   Same spacing, same corner radius, same shadows, same motion rules everywhere, so every new feature feels native from day one.

3. Make the app feel lighter and more human
   Less "rows in a database", more "control center for your presence", with surfaces that feel modern instead of corporate.

4. Use layout to guide people, not confuse them
   Clear sections for Organizations, personal tools, and admin features so your brain always knows where it is in the product.

The entire redesign was basically us asking one question over and over:

If I saw this screen without a logo, would I still know it is OnlyLinks?

If the answer was no, we kept iterating.

The OnlyLinks Brand Guidelines And Design Language

One of the biggest pieces behind v2 is something you do not see on any single screen by itself:

The brand language that sits underneath everything.

Before we touched the product, I sat down and designed a full visual and interaction language for OnlyLinks from the ground up. That work now lives on our public brand guidelines page:

onlylinks.com/brand-guidelines

This is not just a moodboard or a color palette. It is the source of truth for how OnlyLinks should look and feel everywhere:

• The core gradient fields and how they blend into backgrounds
• The glassy surfaces, shadows, and elevation levels
• The typography hierarchy, from big hero headlines down to tiny labels
• The motion rules for how things enter, exit, and react
• The spacing and layout rhythm that keeps screens feeling balanced

Every decision in v2 starts there. If a new screen or component does not fit the language in the brand guidelines, it is wrong until we fix it.

The goal was to create a design language that is recognizably OnlyLinks even without the logo:

• Soft but sharp
• Gradient heavy but still clean
• Modern and fluid without feeling like a Dribbble shot pasted into a real product

The v2 UI is basically that brand system brought to life across the entire app.

Color, Gradients, And Depth

The biggest visual jump is the color.

• Backgrounds are no longer just gray. We use soft gradients and light color washes so the app feels like it has an atmosphere.
• Primary CTAs live on rich, smooth gradients that tie back to the OnlyLinks brand.
• Cards sit on top with subtle shadows and rounded corners, so the interface has real depth instead of feeling stamped on.

Under the hood, this is all driven by a tighter color system:

• A primary gradient set used for navigation and key actions
• A gentle neutral set for backgrounds and card surfaces
• Accent colors reserved for things like alerts, status, and charts

Nothing is neon or loud for no reason. The color is there to show hierarchy and focus, not just to look pretty.

Depth also got a proper structure. Instead of random shadows, we use a small set of elevation levels:

• Base background (almost flat, very soft)
• Cards (slightly lifted)
• Overlays and modals (more lifted, but still soft on the edges)

It keeps everything feeling consistent and helps your brain understand which layer it is interacting with.

Layout And Navigation

We also ripped apart the layout and rebuilt it in a way that matches how people actually use OnlyLinks.

• "Agencies" are now Organizations, which makes more sense for both teams and brands.
• The sidebar is split into clear sections: Organization, Personal, Settings & Tools, and Admin.
• The active item uses a strong gradient pill, so you always know where you are.

On the page level:

• Hero sections at the top give you the key context for where you are and what you are managing.
• Below that, cards and tables are arranged so your eyes flow from most important to supporting details.
• Multi step flows, like onboarding, use clean progress indicators so the path is obvious.

We also paid attention to how layouts collapse and stretch:

• On larger screens, content breathes and forms split into logical columns.
• On smaller screens, everything stacks in a clean, linear order so you are not hunting for inputs or buttons.

The app feels less like "a lot of pages" and more like one connected workspace that just happens to adapt to whatever screen you are on.

Motion And Micro Interactions

We started using motion as part of the brand, not just as a random effect.

• Hover states give clear feedback without feeling jittery.
• Modals and drawers ease in and out with natural timing, so nothing feels like it teleports.
• Small transitions on tabs, filters, and toggles make the interface feel responsive and modern.

We treated motion like seasoning:

• Enough to make the interface feel alive
• Not so much that it slows you down or makes you dizzy

If an animation ever felt like it was showing off in the middle of real work, we toned it down.

Over time, these tiny interactions add up. The product feels smoother, more intentional, and less like a static HTML admin panel.

Building A Real Design System

One big thing that changed behind the scenes is how we think about components.

In v1, a lot of UI was built in a one off way:

• A card over here
• A button variation over there
• A special table style for one screen

In v2, we treated everything as part of a design system:

• Buttons share the same core structure and states across the entire app
• Cards reuse the same spacing, radius, and elevation tokens
• Inputs, selects, and toggles follow one clear style instead of five half related ones

This means:

• Future features like new dashboards or tools can be built faster
• The visual language stays consistent even as the product grows
• The app feels more trustworthy because nothing looks out of place

You might not see this directly as a user, but you feel it every time a new feature shows up and it just blends in.

New Surfaces: Alerts And Custom Domains

During the redesign we also used the new design system to introduce new features.

Alerts

Alerts needed to be noticeable without feeling aggressive.

• We designed alert surfaces as colored cards that sit inside the layout, not ugly banners slapped on top.
• Icons, short titles, and clear actions keep them readable at a glance.
• They follow the same spacing, radius, and shadow rules as the rest of the system, so they feel native to the product.

You get important information in context, without the UI screaming at you or breaking the flow of the page.

Custom Domains

Custom domains are a big part of making a profile feel like a real brand. The old experience for this was very utilitarian and almost hidden.

Now:

• The custom domains area has its own section and card layout, so it feels like a first class part of the product.
• Inputs, status badges, and connection states are all designed with the same gradient and glassy language as the rest of v2.
• Success and error states use consistent colors and messages, so you know exactly what is happening with your domain.

It feels like part of a professional brand tool, not a configuration checkbox buried in settings.

Working On This With The OnlyLinks Team

This was not a solo design sprint. The last 1.5 months have been a loop of:

• Me exploring layouts, flows, and visual directions
• The team poking holes in them, pointing out edge cases, and bringing real user needs into the conversation
• Iterating on the details until the screens felt right both visually and practically

A lot of the best changes came from tiny comments like:

• "What if this stat was promoted to the top instead of buried?"
• "This looks cool but will confuse a new user, can we simplify it?"
• "This section should feel more important, it looks like a secondary card right now."

The end result is a product that looks like something I would design, but also behaves like something a whole team pressure tested.

Why This Redesign Matters

This was not a "change a few colors" update. We rebuilt the UI and UX from the ground up so that:

• The interface finally matches the level of polish creators expect.
• Organizations can manage real businesses in a space that feels premium, not like a random CRM.
• New features like Alerts and Custom Domains drop into a strong design system instead of creating more visual noise.
• The product feels like a single, coherent OnlyLinks experience, not a folder of disconnected pages.

Honestly, this post does not even scratch the surface of all the tiny layout tweaks, motion changes, and new surfaces that went into v2. There are a lot of little details you only notice when you use it in real life.

If you want to really feel the difference, you will just have to jump in and click around OnlyLinks yourself.

Written by Charbel Habchy • Published November 17 2025

When we set out to build OnlyLinks, we knew analytics would be mission-critical. Content creators need real-time insights into their traffic, clicks, and audience behavior—and they need it fast. But traditional analytics solutions either didn't scale well or required rebuilding the wheel from scratch.

Here's how we built an analytics system that handles millions of events while keeping queries blazing fast and costs under control.

The Hybrid Architecture: Best of Both Worlds

Most teams choose either a hosted analytics platform (like PostHog, Mixpanel, or Amplitude) or a data warehouse (like BigQuery, Snowflake, or Redshift). We chose both—and that makes all the difference.

PostHog handles event capture, giving us:

• Battle-tested SDKs for client and server-side tracking
• Automatic session recording and dead click detection
• Rich event properties with GeoIP lookup, device detection, and browser fingerprinting
• A powerful ingestion pipeline that never drops events

BigQuery handles queries, giving us:

• Sub-second queries across billions of rows
• Materialized views that pre-aggregate data
• Clustering and partitioning for optimal performance
• Cost-effective storage with columnar compression

This separation of concerns is key. PostHog is optimized for capturing every single event reliably, while BigQuery is optimized for querying that data efficiently.

The Secret Sauce: Materialized Views

Here's where things get interesting. Raw event data is flexible but slow to query. Traditional analytics platforms force you to define metrics upfront. We found a middle ground: materialized views with intelligent clustering.

We maintain several pre-aggregated views that transform raw events into queryable metrics:

1. Hourly Traffic Aggregation

CREATE MATERIALIZED VIEW analytics.hourly_traffic
CLUSTER BY hour_timestamp, user_path
AS
SELECT
  TIMESTAMP_TRUNC(event_timestamp, HOUR) AS hour_timestamp,
  user_path,
  COUNT(*) AS view_count,
  COUNT(DISTINCT session_id) AS unique_sessions
FROM analytics.raw_events
WHERE event_type = 'page_view'
GROUP BY hour_timestamp, user_path;

Why this matters: Clustering by hour_timestamp and user_path means queries filtering by time range and user are ridiculously fast. BigQuery can skip entire data blocks that don't match your query.

2. Geographic & Device Analytics

CREATE MATERIALIZED VIEW analytics.audience_distribution
CLUSTER BY date, user_path, country_code, device_category
AS
SELECT
  DATE(event_timestamp) AS date,
  user_path,
  COALESCE(geo_country, 'Unknown') AS country_code,
  COALESCE(device_type, 'Unknown') AS device_category,
  COALESCE(browser_name, 'Unknown') AS browser_name,
  COUNT(*) AS event_count
FROM analytics.raw_events
WHERE event_type = 'page_view'
GROUP BY date, user_path, country_code, device_category, browser_name;

The clustering strategy is crucial. BigQuery allows a maximum of 4 clustering fields, so we prioritized based on our most common query patterns:

1. date - nearly all queries filter by date range
2. user_path - filtering by specific users/profiles
3. country_code - geographic analytics are frequently requested
4. device_category - device breakdowns are common

Browser is included but not clustered—a deliberate trade-off we made after analyzing our query patterns.

3. Link Engagement Tracking

CREATE MATERIALIZED VIEW analytics.link_performance
CLUSTER BY date, user_path, destination_url
AS
SELECT
  DATE(event_timestamp) AS date,
  user_path,
  destination_url,
  link_title,
  COUNT(*) AS click_count,
  COUNT(DISTINCT session_id) AS unique_clickers
FROM analytics.raw_events
WHERE event_type = 'link_click'
GROUP BY date, user_path, destination_url, link_title;

This powers our "Top Links" analytics, showing creators which specific links are driving the most engagement.

Redis Caching: The Performance Multiplier

Even with optimized BigQuery queries, hitting the database on every request adds latency. That's where Redis comes in—but not in the way you might expect.

We use multi-level caching with intelligent invalidation:

async function getAnalyticsDashboard(userId: string, timeRange: string) {
  const cacheKey = `analytics:${userId}:${timeRange}`;
  
  // Try Redis first
  const cached = await redis.get(cacheKey);
  if (cached) {
    return JSON.parse(cached);
  }

  // Cache miss - query BigQuery
  const data = await queryBigQueryForDashboard(userId, timeRange);
  
  // Cache for 5 minutes
  await redis.setex(cacheKey, 300, JSON.stringify(data));
  
  return data;
}

Key insight: We cache at the API response level, not individual query results. This means:

• A single cache hit returns the entire analytics dashboard
• Cache invalidation is simple—just a TTL
• No complex dependency tracking between queries

For real-time campaign tracking, we implemented tiered caching with fallback behavior:

async function getCampaignMetrics(campaignId: string) {
  const inMemoryCache = memoryCache.get(campaignId);
  
  // Try in-memory cache first (faster but shorter TTL)
  if (inMemoryCache && Date.now() - inMemoryCache.timestamp < 60000) {
    return inMemoryCache.data;
  }
  
  // Try Redis cache
  const redisCache = await redis.get(`campaign:${campaignId}`);
  if (redisCache) {
    const data = JSON.parse(redisCache);
    memoryCache.set(campaignId, { data, timestamp: Date.now() });
    return data;
  }
  
  // Query database
  const freshData = await queryDatabase(campaignId);
  
  // Update both caches
  await redis.setex(`campaign:${campaignId}`, 300, JSON.stringify(freshData));
  memoryCache.set(campaignId, { data: freshData, timestamp: Date.now() });
  
  return freshData;
}

This ensures analytics are always available, even during database maintenance or temporary outages.

Batch Querying: From N Queries to 1

Here's a problem we ran into early: agency dashboards showing analytics for 100+ creators would make 100+ separate BigQuery queries. Even with caching, cold loads were brutally slow.

Our solution? Batch everything into a single query using CTEs and array parameters.

WITH user_pageviews AS (
  SELECT
    user_path,
    SUM(view_count) AS total_views,
    SUM(unique_sessions) AS total_sessions
  FROM analytics.hourly_traffic
  WHERE user_path IN UNNEST(@user_paths)
    AND hour_timestamp >= @start_date
    AND hour_timestamp < @end_date
  GROUP BY user_path
),
user_clicks AS (
  SELECT
    user_path,
    SUM(click_count) AS total_clicks,
    COUNT(DISTINCT destination_url) AS unique_links
  FROM analytics.link_performance
  WHERE user_path IN UNNEST(@user_paths)
    AND date >= @start_date
    AND date < @end_date
  GROUP BY user_path
),
combined_metrics AS (
  SELECT
    pv.user_path,
    pv.total_views,
    pv.total_sessions,
    cl.total_clicks,
    cl.unique_links,
    SAFE_DIVIDE(cl.total_clicks, pv.total_views) * 100 AS ctr
  FROM user_pageviews pv
  LEFT JOIN user_clicks cl USING (user_path)
)
SELECT * FROM combined_metrics
ORDER BY total_views DESC;

Then in our application code:

async function getAgencyDashboard(agencyId: string, period: string) {
  // Get all creator paths for this agency
  const creators = await db.getAgencyCreators(agencyId);
  const userPaths = creators.map(c => c.path);
  
  // Single batched query instead of N queries
  const results = await bigquery.query({
    query: BATCH_ANALYTICS_QUERY,
    params: {
      user_paths: userPaths,
      start_date: getStartDate(period),
      end_date: new Date()
    }
  });
  
  return processResults(results);
}

The impact: Agency dashboards went from 15-30 seconds to load down to under 2 seconds. And because we're processing data in BigQuery instead of in our application servers, we use far less memory and CPU.

Intelligent Anomaly Detection

Here's something most analytics platforms don't do: proactive alerting for traffic anomalies.

We built automated detection that runs daily to identify unusual patterns:

Traffic Spike & Drop Detection

WITH daily_stats AS (
  SELECT
    user_path,
    DATE(hour_timestamp) AS date,
    SUM(view_count) AS daily_views
  FROM analytics.hourly_traffic
  WHERE hour_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 14 DAY)
  GROUP BY user_path, date
),
baseline_comparison AS (
  SELECT
    user_path,
    AVG(CASE WHEN date < CURRENT_DATE() THEN daily_views END) AS avg_views,
    MAX(CASE WHEN date = CURRENT_DATE() THEN daily_views END) AS today_views
  FROM daily_stats
  GROUP BY user_path
  HAVING avg_views > 100  -- Only users with meaningful traffic
),
anomaly_detection AS (
  SELECT
    user_path,
    today_views,
    avg_views,
    ((today_views - avg_views) / avg_views) * 100 AS percent_change,
    CASE
      WHEN today_views < avg_views * 0.5 THEN 'DROP'
      WHEN today_views > avg_views * 2.0 THEN 'SURGE'
      ELSE 'NORMAL'
    END AS alert_type
  FROM baseline_comparison
)
SELECT *
FROM anomaly_detection
WHERE alert_type != 'NORMAL';

This runs daily and alerts creators when something unusual happens—like a viral post driving 10x traffic, or a technical issue causing views to plummet.

Click-Through Rate Monitoring

WITH daily_metrics AS (
  SELECT
    user_path,
    DATE(hour_timestamp) AS date,
    SUM(view_count) AS views,
    COALESCE(
      (SELECT SUM(click_count) 
       FROM analytics.link_performance lp 
       WHERE lp.user_path = ht.user_path 
         AND lp.date = DATE(ht.hour_timestamp)),
      0
    ) AS clicks
  FROM analytics.hourly_traffic ht
  WHERE hour_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 14 DAY)
  GROUP BY user_path, date
),
ctr_analysis AS (
  SELECT
    user_path,
    AVG(SAFE_DIVIDE(clicks, views) * 100) AS avg_ctr,
    MAX(CASE WHEN date = CURRENT_DATE() 
        THEN SAFE_DIVIDE(clicks, views) * 100 
        END) AS today_ctr
  FROM daily_metrics
  WHERE views > 50  -- Statistical significance threshold
  GROUP BY user_path
)
SELECT
  user_path,
  today_ctr,
  avg_ctr,
  ((today_ctr - avg_ctr) / avg_ctr) * 100 AS ctr_change_percent
FROM ctr_analysis
WHERE ABS((today_ctr - avg_ctr) / avg_ctr) > 0.5  -- 50% change threshold
ORDER BY ABS((today_ctr - avg_ctr) / avg_ctr) DESC;

Why this matters: A creator's CTR dropping 50% might indicate broken links, confusing copy, or audience mismatch. Catching this early helps creators optimize their pages before losing significant engagement.

Performance Monitoring Built-In

Every query logs its resource usage to help us optimize costs:

async function executeMonitoredQuery(sql: string, params: any) {
  const startTime = Date.now();
  
  const [job] = await bigquery.createQueryJob({ query: sql, params });
  const [rows] = await job.getQueryResults();
  const [metadata] = await job.getMetadata();
  
  const stats = {
    duration: Date.now() - startTime,
    bytesProcessed: metadata.statistics.totalBytesProcessed,
    bytesBilled: metadata.statistics.totalBytesBilled,
    rowsReturned: rows.length
  };
  
  // Log to monitoring service
  logger.info('BigQuery execution', {
    query: sql.substring(0, 100),
    ...stats,
    costEstimate: (stats.bytesBilled / 1e12) * 5 // $5 per TB
  });
  
  // Alert if query is expensive
  if (stats.bytesBilled > 1e9) { // > 1GB
    alerts.notify('Expensive query detected', stats);
  }
  
  return rows;
}

This gives us real-time visibility into query costs. We've optimized several queries by 90%+ just by reviewing these logs.

For example, we discovered that adding a date filter reduced bytes processed from 500 MB to 50 MB for a common dashboard query—saving ~$0.002 per query, which adds up to $120/month at our query volume.

Parallel Execution with Graceful Degradation

When loading a dashboard, we fetch all metrics in parallel with individual error handling:

async function loadDashboard(userId: string, period: string) {
  const [
    trafficData,
    topLinks,
    geoDistribution,
    deviceBreakdown,
    sessionMetrics
  ] = await Promise.allSettled([
    getTrafficTimeseries(userId, period),
    getTopPerformingLinks(userId, period),
    getGeographicDistribution(userId, period),
    getDeviceBreakdown(userId, period),
    getSessionMetrics(userId, period)
  ]);
  
  return {
    traffic: trafficData.status === 'fulfilled' ? trafficData.value : null,
    topLinks: topLinks.status === 'fulfilled' ? topLinks.value : [],
    geography: geoDistribution.status === 'fulfilled' ? geoDistribution.value : [],
    devices: deviceBreakdown.status === 'fulfilled' ? deviceBreakdown.value : [],
    sessions: sessionMetrics.status === 'fulfilled' ? sessionMetrics.value : null,
    hasErrors: [trafficData, topLinks, geoDistribution, deviceBreakdown, sessionMetrics]
      .some(r => r.status === 'rejected')
  };
}

Each query has a fallback so one failure doesn't break the entire dashboard. If the "Geographic Distribution" query fails, we show an empty state—but traffic, clicks, and other metrics still load.

Parameterized Queries for Security & Performance

All queries use named parameters instead of string interpolation:

const sql = `
  SELECT
    user_path,
    SUM(view_count) AS total_views
  FROM analytics.hourly_traffic
  WHERE user_path = @userId
    AND hour_timestamp >= @startDate
    AND hour_timestamp < @endDate
  GROUP BY user_path
`;

const results = await bigquery.query({
  query: sql,
  params: {
    userId: '/creator-username',
    startDate: '2024-01-01T00:00:00Z',
    endDate: '2024-01-31T23:59:59Z'
  }
});

This provides:

• SQL injection protection (even though we're server-side)
• Better query plan caching in BigQuery (identical queries with different params reuse plans)
• Type safety for parameters
• Cleaner, more maintainable code

What We Learned

Building this analytics system taught us a few key lessons:

1. Don't reinvent event capture. Use a proven platform like PostHog, Segment, or RudderStack. Focus your energy on the analytics experience, not the infrastructure.

2. Materialized views are a cheat code. The upfront cost of defining views pays off 100x in query performance. Start with simple aggregations and iterate based on usage.

3. Cluster by your query patterns. Study your most common queries and cluster accordingly. Don't just cluster by date—consider user paths, categories, or other frequently-filtered dimensions.

4. Cache aggressively, invalidate simply. TTL-based caching is good enough for 99% of analytics use cases. Don't over-engineer it with complex invalidation logic.

5. Batch queries ruthlessly. One complex query with CTEs is almost always faster than many simple queries, especially across a network. Plus, you save on per-query overhead.

6. Build in observability from day one. Logging bytes processed helped us optimize costs before they became a problem. Treat query performance as a first-class metric.

7. Graceful degradation > perfect data. It's better to show partial analytics than to show nothing when one query fails. Users understand temporary gaps—they don't understand blank screens.

8. Anomaly detection adds massive value. Proactive alerts about traffic changes help users catch problems early and capitalize on viral moments. This feature gets mentioned in user feedback constantly.

The Results

Today, our analytics system handles:

• 10M+ events per day ingested through PostHog
• Sub-second queries for individual creator dashboards
• 2-second load times for agency dashboards aggregating 100+ creators
• 99.9% uptime with automatic failover to cached data

And most importantly: creators love it. They trust the data, rely on the alerts, and use insights to optimize their pages. We see 70%+ of active users checking their analytics at least weekly.

Technical Architecture Summary

Here's a quick reference of our stack:

• Event Capture: PostHog (exports to BigQuery)
• Data Warehouse: Google BigQuery
• Caching: Redis
• API Layer: tRPC for type-safe endpoints
• Frontend: React + Recharts for visualizations
• Monitoring: Custom logging + CloudWatch alerts

Next Steps

We're continuously improving our analytics system. On the roadmap:

• Predictive analytics: Use historical patterns to forecast future traffic
• Cohort analysis: Track user retention and engagement over time
• Custom metrics: Let creators define their own KPIs
• Real-time streaming: Sub-minute data freshness for critical metrics
• Machine learning alerts: Smarter anomaly detection using ML models

Want to see it in action? Sign up for OnlyLinks and check out the analytics dashboard. It's fast, reliable, and built with the techniques described in this post.

Have questions about our architecture? We love talking about analytics infrastructure. Email us @ support@onlylinks.com.

Written by the James Ash • Published November 2025