Partition for how you query, not how you load
Teams partition by load date because that's how the data arrives. Then every analytical query scans the whole table, because nobody queries by load date. Partition for the reader.
Partitioning decides which slices of a table a query has to read. Choose well and a query touches one partition; choose by habit and it scans everything. The common mistake is partitioning by the convenient thing — the date the batch ran — when the questions people ask filter on something else entirely.
Follow the WHERE clause
Look at how the table is actually queried. If 90% of queries filter on event date, partition on event date. If they filter on a tenant or region, consider that. The partition key should match the predicate that appears most often, so the engine can prune the partitions it doesn't need.
The right partition key is usually sitting in the most common WHERE clause. Read your query logs before you guess.
Don't over-partition
The opposite failure is partitioning so finely — by hour, by user — that you get millions of tiny files and the overhead of listing them dwarfs the savings. Aim for partitions in a sensible size range; daily is right for many tables, hourly only when volume and query patterns justify it.
Loading is a separate concern
If data arrives by load date but is queried by event date, that's fine: load into a staging area keyed however it arrives, then write into the analytical table partitioned by event date. The reader's experience is what the partition scheme should optimize for — the loader can adapt.