Creating redshift-useful-sql page from archived help.segment.com page

Author: forstisabella

src/connections/storage/warehouses/redshift-useful-sql.md

@@ -0,0 +1,344 @@
+---
+title: Useful SQL Queries for Redshift
+---
+Below you'll find a library of some of the most useful SQL queries customers use in their Redshift warehouses. You can run these right in your Redshift instance with little to no modification.
+
+> note " "
+> If you're looking for SQL queries for warehouses other than Redshift, check out some of our [Analyizing with SQL guides](/docs/connections/storage/warehouses/index/#analyzing-with-sql).
+
+## Tracking events
+
+The track allows you to record any actions your users perform. A track call takes three parameters: the userId, the event, and any optional properties.
+
+Here's a basic track call:
+
+```javascript
+analytics.track('Completed Order',
+  item: 'pants',
+  color: 'blue'
+  size: '32x32'
+  payment: 'credit card'
+});
+```
+
+And another completed order track call might look like this:
+
+```javascript
+analytics.track('Completed Order', {
+ item: 'shirt',
+ color: 'green'
+ size: 'Large'
+ payment: 'paypal'
+});
+```
+
+Each track call is stored as a distinct row in a single Redshift table called `tracks`. To get a table of your completed orders, you can run the following query: 
+
+```sql
+select *
+from initech.tracks
+where event = 'completed_order'
+```
+
+This SQL query returns a table that looks like this:
+
+| event           | event_id | user_id    | sent_at             | item  | color  | size   | payment     | 
+| --------------- | -------- | ---------- | ------------------- | ----- | ------ | ------ | ----------- |
+| completed_order | jrse3pyf | BQ9R7u4NA9 | 2021-12-09 03:50:00 | pants | blue   | 32x33  | credit card |
+| completed_order | cxntjkc7 | TQ9D7x4NA4 | 2021-12-09 02:50:01 | pants | green  | 31x33  | credit card |
+| completed_order | xjuvaely | APR97u8NB9 | 2021-12-09 01:50:39 | shirt | red    | Medium | credit card |
+| completed_order | rft31ial | ly3jaeillp | 2021-12-09 08:50:13 | shirt | yellow | Large  | credit card | 
+| completed_order | k8bhgc6h | X9G5Qg0tha | 2021-12-09 07:20:19 | shirt | yellow | Small  | paypal      |
+
+But why are there columns in the table that weren't a part of our **track** call, like `event_id`? 
+This is because the track method automatically includes additional properties of the event, like `event_id`, `sent_at`, and `user_id` (for client-side libraries)!
+
+## Grouping events by day
+If you want to know how many orders were completed over a span of time, you can use the `date()` and `count` function with the `sent_at` timestamp:
+
+```sql
+select date(sent_at) as date, count(event)
+from initech.tracks
+where event = 'completed_order'
+group by date
+```
+That query will return a table like this:
+
+| date       | count |
+| ---------- | ----- |
+| 2021-12-09 | 5     |
+| 2021-12-08 | 3     |
+| 2021-12-07 | 2     |
+
+If you wanted to see how many pants and shirts were sold on each of those dates, you can query that using case statements:
+
+```sql 
+select date(sent_at) as date,
+sum(case when item = 'shirt' then 1 else 0 end) as shirts,
+sum(case when item = 'pants' then 1 else 0 end) as pants
+from initech.tracks
+where event = 'completed_order'
+group by date
+```
+
+That query returns a table like this: 
+
+| date       | shirts | pants |
+| ---------- | ------ | ----- |
+| 2021-12-09 | 3      | 2     |
+| 2021-12-08 | 1      | 2     |
+| 2021-12-07 | 2      | 0     |
+
+
+## Defining sessions
+Segment’s API does not impose any restrictions on your data with regard to user sessions.
+
+Sessions aren’t fundamental facts about the user experience. They’re stories we build around the data to understand how customers actually use the product in their day-to-day lives. And since Segment’s API is about collecting raw, factual data, we don’t have an API for collecting sessions. We leave session interpretation to our partners, which let you design how you measure sessions based on how customers use your product.
+
+### How to define user sessions using SQL
+Each of our SQL partners allows you to define sessions based on your specific business needs. With Looker, for example, you can take advantage of their persistent derived tables and LookML modeling language to layer sessionization on top of your Segment SQL data. We recommend checking out their approach here!
+
+For defining sessions with raw SQL, the best query and explanation we’ve come across is from our friends at Mode Analytics.
+
+Here’s the query to make it happen, but we definitely recommend checking out their blog post as well! They walk you through the reasoning behind the query, what each portion accomplishes, how you can tweak it to suit your needs, and what kind of further analysis you can do on top of it.
+
+```sql
+-- Finding the start of every session
+SELECT *
+  FROM (
+       SELECT *
+              LAG(sent_at,1) OVER (PARTITION BY user_id ORDER BY sent_at) AS last_event
+        FROM "your_source".tracks
+      ) last
+WHERE EXTRACT('EPOCH' FROM sent_at) - EXTRACT('EPOCH' FROM last_event) >= (60 * 10)
+   OR last_event IS NULL
+
+-- Mapping every event to its session
+SELECT *,
+       SUM(is_new_session) OVER (ORDER BY user_id, sent_at ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS global_session_id,
+       SUM(is_new_session) OVER (PARTITION BY user_id ORDER BY sent_at ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS user_session_id
+  FROM (
+       SELECT *,
+              CASE WHEN EXTRACT('EPOCH' FROM sent_at) - EXTRACT('EPOCH' FROM last_event) >= (60 * 10) 
+                     OR last_event IS NULL 
+                   THEN 1 ELSE 0 END AS is_new_session
+         FROM (
+              SELECT *,
+                     LAG(sent_at,1) OVER (PARTITION BY user_id ORDER BY sent_at) AS last_event
+                FROM "your_source".tracks
+              ) last
+       ) final
+```
+
+## Identifying users
+
+### Historical traits
+
+The `identify` method ties user attributes to a `userId`. 
+
+```javascript
+analytics.identify('bob123',{
+  email: '[email protected]',
+  plan: 'Free'
+});
+```
+As these user traits change over time, you can continue calling the identify method to update their changes. Here we’ll update Bob’s account plan to “Premium”.
+
+```javascript
+analytics.identify('bob123', {
+  email: '[email protected]',
+  plan: 'Premium'
+});
+```
+
+Each identify call is stored in a single Redshift table called `identifies`. To see how a user's plan changes over time, you can run the following query: 
+
+```sql
+select email, plan, sent_at
+from initech.identifies
+where email = '[email protected]'
+```
+
+This SQL query returns a table of Bob's account information, with each entry representing the state of his account at different time periods:
+
+| user_id | email          | plan    | sent_at             |
+| ------- | -------------- | ------- | ------------------- |
+| bob123  | [email protected] | Premium | 2013-12-20 19:44:03 |
+| bob123  | [email protected] | Basic   | 2013-12-18 17:48:10 |
+
+If you want to see what your users looked like at a previous point in time, that data is right there in your `identifies` table! (To get this table for your users, replace ‘initech’ with your source slug).
+
+But what if you only want to see the most recent state of the user? Luckily, we can convert the `identifies` table into a distinct users table by taking the most recent identify call for each account.
+
+## Converting The identifies table into a users table
+
+The following query will return your `identifies` table: 
+
+```sql
+select *
+from initech.identifies
+```
+That query returns a table like this:
+
+| user_id  | email           | plan    | sent_at             |
+| -------  | --------------  | ------- | ------------------- |
+| bob123   | [email protected]  | Premium | 2013-12-20 19:44:03 |
+| bob123   | [email protected]  | Basic   | 2013-12-18 17:48:10 |
+| jeff123  | [email protected] | Premium | 2013-12-20 19:44:03 |
+| jeff123  | [email protected] | Basic   | 2013-12-18 17:48:10 |
+
+if all you want is a table of distinct user with their current traits and without duplicates, you can do so with the following query:
+
+```sql
+with identifies as (
+  select user_id,
+         email,
+         plan,
+         sent_at,
+         row_number() over (partition by user_id order by sent_at desc) as rn
+  from initech.identifies
+),
+users as (
+  select user_id, 
+         email,
+         plan
+  from identifies
+  where rn = 1
+)
+
+select *
+from users
+```
+
+## Counts of user traits
+Let's say you have an `identifies` table that looks like this:
+
+| user_id  | email           | plan    | sent_at             |
+| -------  | --------------  | ------- | ------------------- |
+| bob123   | [email protected]  | Premium | 2013-12-20 19:44:03 |
+| bob123   | [email protected]  | Basic   | 2013-12-18 17:48:10 |
+| jeff123  | [email protected] | Premium | 2013-12-20 19:44:03 |
+| jeff123  | [email protected] | Basic   | 2013-12-18 17:48:10 |
+
+If we want to query the traits of these users, we first need to [convert the identifies table into a users table](#converting-the-identifies-table-into-a-users-table) From there, we can run a query like this to get a count of users with each type of plan:
+
+```sql
+with identifies as (
+  select user_id,
+         email,
+         plan,
+         sent_at,
+         row_number() over (partition by user_id order by sent_at desc) as rn
+  from initech.identifies
+),
+users as (
+  select plan
+  from identifies
+  where rn = 1
+)
+
+select sum(case when plan = 'Premium' then 1 else 0 end) as premium,
+       sum(case when plan = 'Free' then 1 else 0 end) as free
+from users
+```
+
+And there you go: a count of users with each type of plan!
+
+| premium | free |
+| ------- | ---- |
+| 2       | 0    |
+
+## Groups to accounts
+
+### Historical Traits
+
+The `group` method ties a user to a group. Be it a company, organization, account, source, team or whatever other crazy name you came up with for the same concept! It also lets you record custom traits about the group, like industry or number of employees.
+
+Here’s what a basic `group` call looks like:
+
+```javascript
+analytics.group'0e8c78ea9d97a7b8185e8632', {
+  name: 'Initech',
+  industry: 'Technology',
+  employees: 329,
+  plan: 'Premium'
+});
+```
+As these group traits change over time, you can continue calling the group method to update their changes.
+
+```javascript
+analytics.group('0e8c78ea9d97a7b8185e8632', {
+  name: 'Initech',
+  industry: 'Technology',
+  employees: 600,
+  plan: 'Enterprise'
+});
+```
+
+Each group call is stored as a distinct row in a single Redshift table called `groups`. To see how a group changes over time, you can run the following query: 
+
+```sql
+select name, industry, plan, employees, sent_at
+from initech.groups
+where name = 'Initech'
+```
+
+The previous query will return a table of Initech's group information, with each entry representing the state of the account at different times.
+
+| name    | industry   | employees | plan    | sent_at             |
+| ------- | ---------- | --------- | ------- | ------------------- |
+| Initech | Technology | 600       | Premium | 2021-12-20 19:44:03 |
+| Initech | Technology | 349       | Free    | 2013-12-18 17:18:15 |
+
+If you want to see a group’s traits at a previous point in time, that data is right there in your groups table! (To get this table for your groups, replace ‘initech’ with your source slug).
+
+But what if you only want to see the most recent state of the group? You can convert the groups table into a distinct groups table by taking the most recent groups call for each account.
+
+### Converting the Groups Table into an Organizations Table
+
+The following query will return your groups table:
+
+```sql
+select *
+from initech.groups
+```
+
+The previous query returns the following table:
+
+| name      | industry      | employees | plan    | sent_at             |
+| --------- | ------------- | --------- | ------- | ------------------- |
+| Initech   | Technology    | 600       | Premium | 2021-12-20 19:44:03 |
+| Initech   | Technology    | 349       | Free    | 2013-12-18 17:18:15 |
+| Acme Corp | Entertainment | 15        | Premium | 2021-12-20 19:44:03 |
+| Acme Corp | Entertainment | 10        | Free    | 2013-12-18 17:18:15 |
+
+However, if all you want is a table of distinct groups and current traits, you can do so with the following query:
+
+```sql
+with groups as (
+  select name,
+         industry,
+         employees,
+         plan,
+         sent_at,
+         row_number() over (partition by name order by sent_at desc) as rn
+  from initech.groups
+),
+organizations as (
+  select name,
+         industry,
+         employees,
+         plan
+  from groups
+  where rn = 1
+)
+
+select *
+from organizations
+```
+This query will retun a table with your distinct groups, without duplicates!
+
+| name      | industry      | employees | plan    | sent_at             |
+| --------- | ------------- | --------- | ------- | ------------------- |
+| Initech   | Technology    | 600       | Premium | 2021-12-20 19:44:03 |
+| Acme Corp | Entertainment | 15        | Premium | 2021-12-20 19:44:03 |