Competitor analysis #143
Competitor analysis #143
Conversation
| chains_supported_by_cow as ( | ||
| select distinct blockchain | ||
| from | ||
| dex_aggregator.trades | ||
| where | ||
| project = 'cow_protocol' | ||
| ), | ||
|
|
||
| all_competitor_transactions as ( | ||
| select | ||
| tx_from as address, | ||
| blockchain as chain_used_for_competitor, | ||
| project as competitor_project, | ||
| sum(amount_usd) as competitor_total_volume_usd, | ||
| count(*) as competitor_total_transactions | ||
| from | ||
| dex.trades | ||
| where | ||
| blockchain in (select blockchain from chains_supported_by_cow) | ||
| and | ||
| block_time between timestamp '{{start_time}}' and timestamp '{{end_time}}' | ||
| group by 1, 2, 3 | ||
|
|
||
| union all | ||
|
|
||
| select | ||
| tx_from as address, | ||
| blockchain as chain_used_for_competitor, | ||
| project as competitor_project, | ||
| sum(amount_usd) as competitor_total_volume_usd, | ||
| count(*) as competitor_total_transactions | ||
| from | ||
| dex_aggregator.trades | ||
| where | ||
| project != 'cow_protocol' | ||
| and | ||
| blockchain in (select blockchain from chains_supported_by_cow) | ||
| and | ||
| block_time between timestamp '{{start_time}}' and timestamp '{{end_time}}' | ||
| group by 1, 2, 3 | ||
| ), |
There was a problem hiding this comment.
Instead of duplicating this query, can we express it in terms of the other query (if necessary defining a third shared query, which is used by the other two)?
Cf. mevblocker fee calculation as an example trying to reduce code duplication to a minimum.
There was a problem hiding this comment.
I'd prefer to keep it like this until we start seeing that more queries are starting to use the same CTE combo. Refactoring to reduce code duplication would also decrease readability + reduce the ease of forking query in UI to perform ad-hoc analysis.
There was a problem hiding this comment.
P.S. I would still do the union before aggregation to reduce that sort of duplication
There was a problem hiding this comment.
I'd really encourage you going forward to think if you can design similar queries (like these two) in ways that share as much as code as possible. You will see that otherwise maintaining a coherent way of doing analysis will become increasingly difficult (e.g. someone may notice a flaw in one of the queries and will want to fix it; now that person needs to somehow know that there are other queries which use the same base logic and would also need to be fixed as otherwise we are starting to see incoherent results).
| blockchain in (select blockchain from chains_supported_by_cow) | ||
| and | ||
| block_time between timestamp '{{start_time}}' and timestamp '{{end_time}}' | ||
| ), | ||
|
|
||
| all_competitor_transactions as ( | ||
| select | ||
| tx_from as address, | ||
| blockchain as chain_used_for_competitor, | ||
| project as competitor_project, | ||
| sum(amount_usd) as competitor_total_volume_usd, | ||
| count(*) as competitor_total_transactions | ||
| from | ||
| trades_dex_and_aggregators | ||
| group by 1, 2, 3 | ||
| ), | ||
|
|
||
| agg as ( | ||
| select | ||
| chain_used_for_cow, | ||
| chain_used_for_competitor, | ||
| competitor_project, | ||
| count(distinct address) as distinct_users_competitor, | ||
| sum(total_transactions_on_cow) as transactions_made_on_cow, | ||
| sum(total_volume_usd_on_cow) as total_volume_usd_on_cow, | ||
| sum(competitor_total_transactions) as transactions_made_on_competitor, | ||
| sum(competitor_total_volume_usd) as total_volume_usd_on_competitor | ||
| from | ||
| cow_protocol_target_users |
There was a problem hiding this comment.
Is it better to do a seperate join for just one additional line, or group it one, with 2 joins
There was a problem hiding this comment.
If you are talking about joining users_per_chain_cow - I keep it out for readability
|
Please review latest version @fleupold @PoloX2021 |
|
LGTM |
Added competitor analysis queries to the dune queries repo