Etv Events

[Latisha Gervase]

Anevent allows you to measure a specific interaction or occurrence on your website or app. For example, you can use an event to measure when someone loads a page, clicks a link, or completes a purchase, or to measure system behavior, such as when an app crashes or an impression is served.

A key event is an event that measures an action that's particularly important to the success of your business. When someone triggers the event by performing the action, the key event is recorded in Google Analytics and surfaced in your Google Analytics reports.

Any event you collect can become a key event. To measure a key event, create or identify an event that measures the action and then mark the event as a key event. After you mark the event as a key event, you can see how many users perform the action and evaluate marketing performance across all channels that lead users to perform the action.

Note: When a user's device goes offline (for example, a user loses internet access while browsing your app), Analytics stores event data on their device and then sends the data once their device is back online. Analytics ignores events that arrive more than 72 hours after the events were triggered.

You can also use the Events API via Socket Mode to receive events through a dynamic private WebSocket, rather than a static public HTTP endpoint. This is useful for those developing behind a corporate firewall, or have other security concerns.

The Events API is recommended over the RTM API for most use cases. If you're already familiar with HTTP and are comfortable maintaining your own server, handling the request and response cycle of the Events API should be familiar. If the world of web APIs is new to you, the Events API is a great next step after mastering incoming webhooks or the Web API.

Before starting, you may want to make a few early decisions about your application architecture and approach to consuming events. The Events API is best used in conjunction with other platform features.

One way to use the Events API is as an alternative to opening WebSocket connections to the RTM API. Why choose the Events API over the RTM API? Instead of maintaining one or more long-lived connections for each workspace an application is connected to, you can set up one or more endpoints on your own servers to receive events atomically in near real-time. For more information, refer to Events API FAQ.

Some developers may want to use the Events API as a kind of redundancy for their existing WebSocket connections. Other developers will use the Events API to receive information around the workspaces and users they are acting on behalf, to improve their slash commands, bot users, notifications, or other capabilities. With app events, you can track app uninstallation, token revocation, Enterprise Grid migration, and more. Handle anything else your app does by using incoming webhooks and other write-based web API methods.

The Events API leverages Slack's existing object-driven OAuth scope system to control access to events. For example, if your app has access to files through the files:read scope, you can choose to subscribe to any or none of the file-related events such as file_created and file_deleted.

You will only receive events that users who have authorized your app can "see" on their workspace (that is, if a user authorizes access to private channel history, you'll only see the activity in private channels they are a member of, not all private channels across the workspace).

To begin working with the Events API, you'll need to create a Slack app if you haven't already. While managing your application, find the Event Subscriptions setting and use the toggle to turn it on.

Your Request URL will receive JSON-based payloads containing wrapped event types. The volume of events will vary depending on the events you subscribe to, and the size and activity of the workspaces that install your application.

Your Request URL might receive many events and requests. Consider decoupling your ingestion of events from the processing and reaction to them. Review the section on rate limiting to better understand the maximum event volume you may receive.

Your Event Request URL must be confirmed before saving this form. If your server takes some time to "wake up" and your initial attempt at URL verification fails due to a timeout, use the retry button to attempt verification again. Careful, response URLs are case-sensitive.

The events sent to your Request URL may contain sensitive information associated with the workspaces having approved your Slack app. To ensure that events are being delivered to a server under your direct control, we must verify your ownership by issuing you a challenge request.

Especially when working with large workspaces, many workspaces, or subscribing to a large number of events, de-coupling the processing of and reaction to events is key. With this challenging handshake complete, you're ready to open up our event type catalog and decide which events to subscribe to.

For any workspaces that have yet to install your application, you'll need to request the specific OAuth scopes corresponding to the event types you're subscribing to. If you're working on behalf of a bot user, you'll need your bot installed the typical way, using the bot OAuth scope.

Authorize users for your Event Consumer app through the standard OAuth flow. Be sure to include all of the necessary scopes for the events your app wants to receive. Consult our index of the available event types with corresponding OAuth scopes.

You may want to consider the number of workspaces you serve, the number of users on those workspaces, their volume of messages, and other activity to evaluate how many requests your Request URL may receive and scale accordingly.

The authorized_users property is an array that contains a set of one or more userswho are authorized to view the event. A user can be a bot user or a human user whoinstalled the app. For each user in the authorized_users property:

The team_id property on the event's outer payload will mirror the first element in the authorized_users array. If you need a complete list of every authorized user for an event, you can useapps.event.authorizations.list.

The event attribute contains a JSON hash for the corresponding event type. The event wrapper is an event envelope of sorts, and the event field represents the contents of that envelope. Learn more about the event wrapper, including its JSON schema.

The structure of event types vary from type to type, depending on the kind of action or object type they represent. The Events API allows you to tolerate minor changes in event type and object type structures, and to expect additional fields you haven't encountered before or fields that are only conditionally present.

If you're already familiar with the RTM API, you'll find that the inner event structure is identical to corresponding events, but are wrapped in a kind of event envelope in the callbacks we send to your event Request URL:

If multiple users on one workspace have installed your app and can "see" the same event, we will send one event and include a list of users to whom this event is "visible" in the authed_users field. For example, if a file was uploaded to a channel that two of your authorized users were party to, we would stream the file_uploaded event once and indicate both of those users in the authed_users array.

Previously, the Events API included a full list of authed_users, and sometimes authed_teams, with every event. These fields displayed who the event is visible to. For example, if your app has been installed by two users in a workspace, and the app listens for the file_shared event, your app might receive an event with authed_users containing those two users.

Now, authed_users and authed_teams are deprecated. Events will contain a single, compact authorizations field that shows one installation of your app that the event is visible to. In other words, lists of authorizations will be truncated to one element.

To get a full list of who can see events, call the apps.event.authorizations.list method after obtaining an app-level token. Read more on the changes here; they have taken effect for existing apps as of February 24, 2021.

Not all events provide an event_context. Read more about the events where event_context is not applicable, and view a full list of those events. Newly created apps are automatically opted into the new form of events: a single, truncated authorizations field with one authorization shown.

You can also use the apps.event.authorizations.list method immediately, without yet opting in to the event payload changes. These changes allow Slack to increase the performance of the Events API, delivering events faster.

Your app should respond to the event request with an HTTP 2xx within three seconds. If it does not, we'll consider the event delivery attempt failed. After a failure, we'll retry three times, backing off exponentially. Some best practices are to:

Maybe it'll trigger you to send a message using chat.postMessage. Maybe you'll update a leaderboard. Maybe you'll update a piece of data you're storing. Maybe you'll change the world or just decide to do nothing at all.

Event deliveries currently max out at 30,000 per workspace per app per 60 minutes. If your app would receive more than one workspace's 30,000 events in a 60 minute window, you'll receive app_rate_limited events describing the conditions every minute.

As Slack sends your request URL events, we ask that you return a HTTP 200 OK for each event you successfully receive. You may respond with a HTTP 301 or 302 and we'll follow up to two redirects in our quest for you to provide us a HTTP 200 success code. Respond with success conditions to at least 5% of the events delivered to your app or risk being temporarily disabled.

Once you've repaired your ability to handle events, re-enable subscriptions by visiting Slack app management, selecting your app, and following the prompts. You'll need to go to Live App Settings if your app is part of the directory.

3a8082e126