MYSQL 计算转化率

Question

I could manage to return the correct Conversion Rate with this query:

SELECT date(ordertime), (count(*) / ( SELECT sum(uniquevisits) FROM s_statistics_visitors WHERE datum = '2020-11-25') * 100) AS 'CONVERSION RATE' FROM s_order WHERE date(ordertime) = '2020-11-25' AND subshopID = 1 GROUP BY date(ordertime);

But it only returns the CR for one specific date. It wont work with the between keyword. The subquery returns more then one result, if I delete the where condition in the subquery.

Schema for s_statistics: id, shopID, datum, uniquevisits, devicetype Schema for s_order: id, ordernumber, ordertime, shopID

Since s_statistics saves values for each devicetype I have to sum uniquevisits per day. But the group by date(ordertime) at the end of my query does not affect the subquery.

-original post- I want to calculate the conversion rate for an onlineshop.

The data is held in two tables.

Schema1 statistics: id / shopID / datum(yyyy-mm-dd) / uniquevisits / devicetype

Schema2 order: id / ordernumber / ordertime (YYYY-MM-DD HH-MM-SS)

Upon my knowledge the conversionrate calculates like:

(unique visits per day / 1000) * orders per day

I tried something like this:

SELECT
((count(ordernumber) / 1000) * (select sum(s_statistics_visitors.uniquevisits) 
FROM s_statistics_visitors GROUP BY* datum))

FROM s_order where subshopID= '1' 
GROUP BY date_format(ordertime, '%d%m%y') 
ORDER BY date_format(ordertime, '%d%m%y')

I know that my query wont work - since there is no join - but I believe it might be the right approach. I could you join on the the date.

The problem: the dateformat in the table: s_statistics_visitors is YYYY-MM-DD

and in order: YYYY-MM-DD HH-MM-SS

Answer 1

You seem to want something like this:

SELECT sv.datum, sv.shopId, count(*) as num_orders,
       (count(*) / 1000) / sv.uniquevisits)
FROM s_order o JOIN
     s_statistics_visitors sv
     ON sv.datum = DATE(o.ordertime) AND
        sv.shopId = o.shopId
GROUP BY sv.datum, sv.shopId, sv.uniqevisits ;

Note: This assumes that shopId is in both tables -- which makes sense for how you have described the problem. If not, you can adjust the shop id logic.