Find the overall acceptance rate of requests rounded to 2 decimals, which is the number of acceptance divided by the number of requests.
This challenge now meets the current minimum standard for sitemap inclusion and independent indexing.
Find the overall acceptance rate of requests rounded to 2 decimals, which is the number of acceptance divided by the number of requests.
Acceptance-rate questions are common because they combine event counting, de-duplication, and ratio math in one compact problem. The same shape appears in activation funnels, confirmation rates, and conversion reporting across product analytics.
sender_idsend_to_idrequest_daterequester_idaccepter_idaccept_dateSELECT
ROUND(
COUNT(DISTINCT requester_id || '-' || accepter_id) * 1.0
/ COUNT(DISTINCT sender_id || '-' || send_to_id),
2
) AS accept_rate
FROM FriendRequest fr
LEFT JOIN RequestAccepted ra
ON fr.sender_id = ra.requester_id
AND fr.send_to_id = ra.accepter_idThis approach keeps the numerator and denominator aligned at the pair level. Distinct pairs prevent duplicate rows from inflating the request or acceptance counts.
WITH requests AS (
SELECT COUNT(DISTINCT sender_id || '-' || send_to_id) AS request_cnt
FROM FriendRequest
),
accepts AS (
SELECT COUNT(DISTINCT requester_id || '-' || accepter_id) AS accept_cnt
FROM RequestAccepted
)
SELECT
ROUND(accept_cnt * 1.0 / request_cnt, 2) AS accept_rate
FROM requests
CROSS JOIN acceptsSeparating the counts into their own CTEs makes auditing easier. This is useful when you want to discuss numerator and denominator logic explicitly instead of mixing everything in one joined query.
Do not use raw COUNT(*) if either table can contain duplicates. Acceptance-rate problems often include repeated request or acceptance rows, so you need to count distinct user pairs instead of physical events.
Because the metric is about whether a request pair exists and whether it was accepted, not how many duplicate event rows were logged for the same pair.
Yes. The denominator is the set of requests sent. The numerator is the subset of those pairs that were accepted, which is why this is a conversion-style rate.
Use these guides when you want the fuller explanation behind the SQL pattern this challenge is testing.
Turn multiple queries into one with conditional aggregation. Learn how CASE WHEN inside aggregate functions creates powerful single-query reports and pivot tables.
Master funnel analysis with SQL. Learn how to track user journeys from landing page to purchase and identify where you are losing customers.
Learn how to add conditional logic to your SQL queries using CASE statements. Transform data and categorize results with ease.
If this problem exposed a deeper weakness, use a topic hub to move through a curated cluster instead of random article hopping.
Analytics
A practical cluster for cohorts, funnels, customer value, and the kinds of reporting questions teams actually ask every week.
Advanced SQL
Use this path when you are moving beyond beginner SELECT queries into CTEs, window functions, and conditional logic.
If you want the rotating practice flow, open this same question from the daily stream. If you want interview-style packaging, continue into the interview pool after this rep.
Compute daily cancellation rate after excluding any trip where either the client or driver is banned.
Return only the customers whose distinct purchased product set covers every product listed in the catalog.
Find products that never appear in the order table without being fooled by missing or duplicate order rows.