Automate feature adoption rate reports from Postgres CSV snapshots in Python and share a single URL

This article shows how to convert raw Postgres CSV snapshots that contain session- and event-level usage into a reproducible, shareable feature adoption rate report you can send to investors and product teams. We'll walk through the exact data expectations, the transformations to compute adoption (overall and by plan tier), code you can run locally, and how to publish the same logic as a one-click Functory API so your growth marketer can open a single URL and see up-to-date numbers.

Long-tail search phrases targeted here include "python feature adoption rate report", "automate feature adoption reporting from postgres csv", and "shareable feature adoption report URL" — each used naturally below.

What this function expects and produces

Input: a CSV snapshot exported from Postgres that contains session or event rows. Expected schema (CSV columns):

• session_id (string) — unique session identifier
• user_id (string) — anonymized customer id
• event_time (ISO 8601 string) — e.g., 2025-03-14T10:23:45Z
• event_name (string) — e.g., 'session_start', 'feature_used'
• feature_name (string, nullable) — e.g., 'batch_invoicing'
• plan_tier (string) — e.g., 'free', 'starter', 'pro', 'enterprise'
• account_created_at (ISO 8601) — used to filter new signups

Transformations performed:

• Parse timestamps and filter by date window (start_date, end_date).
• Define active users as unique user_id with any session or event in the window.
• Define adopters per feature as unique users who triggered event_name='feature_used' with that feature_name at least once in the window.
• Compute adoption rate = adopters / active_users, overall and grouped by plan_tier and cohort (e.g., by signup month).
• Produce CSV and an HTML snippet (bootstrap-free table) that can be embedded or served via a shareable URL.

Output examples:

adoption_by_feature.csv
feature_name,total_active_users,total_adopters,adoption_rate_percent
batch_invoicing,1200,360,30.0
scheduled_reports,1200,180,15.0

adoption_by_feature_by_tier.csv
feature_name,plan_tier,active_users,adopters,adoption_rate_percent
batch_invoicing,pro,300,150,50.0
batch_invoicing,starter,600,150,25.0

Real-world scenario

ChargeFlow, a payments-focused B2B SaaS, exports a daily CSV named usage_snapshot_2025-10-01.csv containing 50,243 rows with columns as above. The product team wants a weekly investor update measuring adoption of two new features: batch_invoicing and dunning. They need:

• Overall adoption rate for each feature in the last 30 days.
• Breakdown by plan_tier (free, starter, pro).
• A shareable URL so non-technical stakeholders can view the latest report without running SQL.

Problem solved: converts raw CSV snapshots into consistent, reproducible adoption numbers and a single URL that always points at the latest run.

Example dataset and the exact problem

Example dataset: 10,000 rows, columns as above, timeframe covering 2025-09-01 to 2025-09-30. Task: compute adoption rates for feature_names ['batch_invoicing','dunning'] between 2025-09-01 and 2025-09-30 and produce CSV + HTML table.

Step-by-step mini workflow

1. Export a CSV snapshot from Postgres: psql -c "COPY (SELECT session_id,user_id,event_time,event_name,feature_name,plan_tier,account_created_at FROM usage_events WHERE event_time >= '2025-09-01') TO STDOUT WITH CSV HEADER" > usage_snapshot_2025-09.csv
2. Run the Python script compute_adoption.py against the CSV and parameters (start_date, end_date, feature list).
3. Script writes adoption_by_feature.csv and adoption_report_2025-09.html.
4. Upload the HTML/CSV to a public URL or publish the script as a Functory function so the team opens a single URL that triggers the script on the latest snapshot.
5. Schedule weekly runs or call the Functory API from your CI to regenerate the report before investor emails.

Algorithm (how it works)

1. Load CSV into pandas; parse event_time as datetime and drop rows with missing user_id.
2. Filter rows to the [start_date, end_date] window.
3. Compute active_users = unique user_id present in filtered rows (optionally exclude bot accounts by plan_tier).
4. For each feature in feature_list, compute adopters = unique user_id where event_name == 'feature_used' and feature_name matches; join with plan_tier to get per-tier counts.
5. Compute adoption_rate = adopters / active_users and format as percent; write CSV and render an HTML table for sharing.

Python implementation (core snippet)

This example is a compact, runnable processing function you can adapt into a small CLI or a service wrapper.

import pandas as pd
from datetime import datetime
from typing import List

def compute_adoption(csv_path: str, features: List[str], start_date: str, end_date: str):
    df = pd.read_csv(csv_path, parse_dates=['event_time', 'account_created_at'])
    df = df.dropna(subset=['user_id'])
    start = pd.to_datetime(start_date)
    end = pd.to_datetime(end_date)
    window = df[(df['event_time'] >= start) & (df['event_time'] <= end)]

    active_users = window['user_id'].nunique()

    rows = []
    for feature in features:
        adopters = window[(window['event_name'] == 'feature_used') & (window['feature_name'] == feature)]['user_id'].nunique()
        rows.append({'feature_name': feature,
                     'total_active_users': active_users,
                     'total_adopters': adopters,
                     'adoption_rate_percent': round(adopters / active_users * 100 if active_users else 0, 2)})

    out_df = pd.DataFrame(rows)
    out_df.to_csv('adoption_by_feature.csv', index=False)
    # simple HTML report
    with open('adoption_report.html', 'w') as f:
        f.write(out_df.to_html(index=False))

# Example call
if __name__ == '__main__':
    compute_adoption('usage_snapshot_2025-09.csv', ['batch_invoicing','dunning'], '2025-09-01', '2025-09-30')

How Functory Makes It Easy

On Functory you would wrap the core logic into a single main(...) entrypoint that accepts strings and file parameters (for example: csv_path: FilePath, features: str (comma-separated), start_date: str, end_date: str). Functory automatically turns those parameters into UI fields and JSON API inputs. When your function returns a path-like value (for example 'adoption_report.html' or 'adoption_by_feature.csv'), Functory exposes that file as a downloadable result and a stable URL the team can open.

Practical steps to publish on Functory:

• Choose an exact Python runtime like 3.11.11.
• Create a requirements.txt with exact pins, e.g., pandas==2.2.3, pyarrow==12.0.0 (one per line).
• Structure code so the platform calls main(...) directly (no CLI wrapper). The main should call your core function and return the path to the generated report.
• Publish — Functory provisions the environment, runs your code on demand, captures prints as logs, and bills per-execution.

Benefits on Functory: no servers to manage, automatic CPU autoscaling for concurrent requests, built-in logging via print(), pay-per-use billing, and straightforward chaining: call a preprocessing function (CSV normalizer) then this adoption-report function from an LLM agent or CI pipeline.

Alternatives and why this approach is better

Teams commonly solve this with one of four patterns: ad-hoc SQL queries in psql, spreadsheets (CSV > Google Sheets), third-party analytics (Mixpanel/Amplitude), or BI dashboards (Looker/Tableau). SQL gives accuracy but is manual; spreadsheets are error-prone and hard to reproduce; third-party analytics can be costly and may not match your event data; BI dashboards require maintenance and often don't produce simple shareable one-click reports for non-technical stakeholders.

This function-based approach centralizes the transformation logic in version-controlled Python, is reproducible across runs, easy to schedule or call from CI, and simple to publish as a one-click URL for non-technical readers. It reduces time spent on manual SQL and spreadsheet wrangling and provides a single canonical source of truth for weekly investor updates.

Business impact

Concrete benefit: automating adoption reporting from CSV snapshots typically reduces manual analyst time from ~4 hours/week to under 30 minutes (setup + validation), a ~88% reduction in human effort for recurring investor reports. For a small B2B SaaS where a senior analyst costs $80k/year, automating weekly reports saves the equivalent of ~0.06 FTE, roughly $5k/year in salary allocation.

Industry stat: According to a 2024 Forrester study, 72% of B2B product teams report that standardized adoption metrics are critical for investor communications and growth decision-making (Forrester, 2024).

Comparison to other developer workflows

Manual scripts: ad-hoc and not discoverable. Notebook workflows: great for exploration but hard to automate and schedule. ETL tools: powerful but heavy and costly for a single weekly report. A single-file Python function turned into a Functory API sits between ad-hoc scripting and heavy ETL: lightweight, versioned, and instantly sharable.