Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Audit docs for negative language #4693

Merged
merged 5 commits into from
Jan 20, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 8 additions & 6 deletions _docs/_api/api_limits.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,19 +9,21 @@ page_type: reference

# API rate limits

The Braze API infrastructure is designed to handle high volumes of data across our customer base. To ensure responsible use of the API, we enforce API rate limits per app group. A rate limit is the number of requests the API can receive in a given time period. If too many requests are sent in a given time frame, you may see error responses with a status code of `429`, which indicates the rate limit has been hit.
The Braze API infrastructure is designed to handle high volumes of data across our customer base. To this end, we enforce API rate limits per app group. A rate limit is the number of requests the API can receive in a given time period. Many load-based denial-of-service incidents in large systems are unintentional—caused by errors in software or configurations—not malicious attacks. Rate limits ensure that such errors don't deprive our customers of Braze API resources. If too many requests are sent in a given time frame, you may see error responses with a status code of `429`, which indicates the rate limit has been hit.

{% alert warning %}
API rate limits and their values (limited or unlimited) are subject to change depending on the proper usage of our system. We encourage sensible limits when making an API call to prevent damage or misuse.
API rate limits are subject to change depending on the proper usage of our system. We encourage sensible limits when making an API call to prevent damage or misuse.
{% endalert %}

## Rate limits by request type

The following table lists specific API rate limits for different request types. All other requests not listed in this table have a default rate limit of 250,000 requests per hour.
The following table lists the default API rate limits for different request types. All other requests not listed in this table have a default rate limit of 250,000 requests per hour.

These default limits can be increased upon request. Reach out to your customer success manager for more information.

| Request Type | Default API Rate Limit |
| --- | --- |
| [`/users/track`][10] | **Requests:** 50,000 requests per minute. This limit can be increased upon request. Reach out to your customer success manager for more information.<br><br>**Batching:** 75 events, 75 purchases, and 75 attributes per API request. See [Batching User Track requests](#batch-user-track) for more. |
| [`/users/track`][10] | **Requests:** 50,000 requests per minute.<br><br>**Batching:** 75 events, 75 purchases, and 75 attributes per API request. See [Batching User Track requests](#batch-user-track) for more. |
| [`/users/export/ids`][11] | 2,500 requests per minute. |
| [`/users/delete`][12]<br>[`/users/alias/new`][13]<br>[`/users/identify`][14]<br>[`/users/merge`][44] | 20,000 requests per minute, shared between the endpoints. |
| [`/users/external_id/rename`][20] | 1,000 requests per minute. |
Expand Down Expand Up @@ -85,12 +87,12 @@ If you have questions about API limits, contact your customer success manager or
### Optimal delay between endpoints

{% alert note %}
We recommend that you allow for a 5-minute delay between consecutive endpoint calls to multiple endpoints to minimize errors.
We recommend that you allow for a five-minute delay between consecutive endpoint calls to multiple endpoints to minimize errors.
{% endalert %}

Understanding the optimal delay between endpoints is crucial when making consecutive calls to the Braze API. Problems arise when endpoints depend on the successful processing of other endpoints, and if called too soon, could raise errors. For example, if you're assigning users an alias via our `/user/alias/new` endpoint, and then hitting that alias to send a custom event via our `/users/track` endpoint, how long should you wait?

Under normal conditions, the time for our data eventual consistency to occur is 10–100ms (1/10 of a second). However, there can be some cases where it takes longer for that consistency to occur. Therefore, we recommend that you allow for a 5-minute delay between making subsequent calls to multiple endpoints to minimize the probability of error. This recommendation does not apply to consecutive endpoint calls to the same endpoint.
Under normal conditions, the time for our data eventual consistency to occur is 10–100ms (1/10 of a second). However, there can be some cases where it takes longer for that consistency to occur. Therefore, we recommend that you allow for a five-minute delay between making subsequent calls to multiple endpoints to minimize the probability of error. This recommendation does not apply to consecutive endpoint calls to the same endpoint.

[1]: {{site.baseurl}}/api/endpoints/messaging/
[2]: {{site.baseurl}}/api/objects_filters/connected_audience/
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,7 @@ Use this endpoint to export all users within a Global Control Group. User data i

## Credentials-based response details

If you have added your S3 credentials to Braze, then each file will be uploaded in your bucket as a zip file with the key format that looks like `segment-export/SEGMENT_ID/YYYY-MM-dd/RANDOM_UUID-TIMESTAMP_WHEN_EXPORT_STARTED/filename.zip`. We will create 1 file per 5,000 users to optimize processing. You can then unzip the files and concatenate all of the `json` files to a single file if needed. If you specify an `output_format` of `gzip`, then the file extension will be `.gz` instead of `.zip`.
If you have [added your S3][1] credentials to Braze, then each file will be uploaded in your bucket as a zip file with the key format that looks like `segment-export/SEGMENT_ID/YYYY-MM-dd/RANDOM_UUID-TIMESTAMP_WHEN_EXPORT_STARTED/filename.zip`. We will create 1 file per 5,000 users to optimize processing. You can then unzip the files and concatenate all of the `json` files to a single file if needed. If you specify an `output_format` of `gzip`, then the file extension will be `.gz` instead of `.zip`.

{% details Export Pathing Breakdown for ZIP File %}
ZIP file format:
Expand All @@ -46,7 +46,7 @@ Example ZIP File:

{% enddetails %}

If you do not have S3 credentials provided, the response to the request provides the URL where a zip file containing all the user files can be downloaded. The URL will only become a valid location once the export is ready. Be aware that if you do not have S3 credentials, there is a limitation on the amount of data that you can export from this endpoint. Depending on the fields you’re exporting and the number of users, the file transfer may fail if it is too large. A best practice is to specify which fields you want to export using ‘fields_to_export’ and specifying only the fields you need, in order to keep the size of the transfer lower. If you want to export all your users and are getting errors generating the file, consider breaking your user base up into more segments based on a random bucket number (e.g. create a segment where random bucket number <1000, between 1000 and 2000, etc).
If you do not have S3 credentials provided, the response to the request provides the URL where a zip file containing all the user files can be downloaded. The URL will only become a valid location once the export is ready. Be aware that if you do not have S3 credentials, there is a limitation on the amount of data that you can export from this endpoint. Depending on the fields you’re exporting and the number of users, the file transfer may fail if it is too large. A best practice is to specify which fields you want to export using ‘fields_to_export’ and specifying only the fields you need, in order to keep the size of the transfer lower. If you want to export all your users and are getting errors generating the file, consider breaking your user base up into more segments based on a random bucket number (e.g., create a segment where random bucket number <1000, between 1000 and 2000, etc).

In either scenario, you may optionally provide a `callback_endpoint` to be notified when the export is ready. If the `callback_endpoint` is provided, we will make a post request to the provided address when the download is ready. The body of the post will be "success":true. If you have not added S3 credentials to Braze, then the body of the post will additionally have the attribute `url` with the download URL as the value.

Expand Down Expand Up @@ -304,4 +304,6 @@ User export object (we will include the least data possible - if a field is miss
{% endtab %}
{% endtabs %}

[1]: {{site.baseurl}}/partners/data_and_infrastructure_agility/cloud_storage/amazon_s3

{% endapi %}
Original file line number Diff line number Diff line change
Expand Up @@ -58,7 +58,7 @@ Example ZIP File:

If you do not have S3 credentials provided but have an Azure integration set up with Braze, the data can be exported there if you have the **Make this the default data export destination** box checked in the Azure partner overview page in Braze. If not, the response to the request provides an obfuscated URL where a zip file containing all the user files can be downloaded. The URL will only become a valid location once the export is ready. We strongly suggest that customers who use this endpoint set up their own S3 credentials so that customers can enforce their own S3 bucket policies on the export.

Be aware that if you do not have S3 credentials, there is a limitation on the amount of data that you can export from this endpoint. Depending on the fields you’re exporting and the number of users, the file transfer may fail if it is too large. A best practice is to specify which fields you want to export using ‘fields_to_export’ and specifying only the fields you need, in order to keep the size of the transfer lower. If you want to export all your users and are getting errors generating the file, consider breaking your user base up into more segments based on a random bucket number (e.g. create a segment where random bucket number <1000, between 1000 and 2000, etc).
Be aware that if you do not have S3 credentials, there is a limitation on the amount of data that you can export from this endpoint. Depending on the fields you’re exporting and the number of users, the file transfer may fail if it is too large. A best practice is to specify which fields you want to export using ‘fields_to_export’ and specifying only the fields you need, in order to keep the size of the transfer lower. If you want to export all your users and are getting errors generating the file, consider breaking your user base up into more segments based on a random bucket number (e.g., create a segment where random bucket number <1000, between 1000 and 2000, etc).

In either scenario, you may optionally provide a `callback_endpoint` to be notified when the export is ready. If the `callback_endpoint` is provided, we will make a post request to the provided address when the download is ready. The body of the post will be "success":true. If you have not added S3 credentials to Braze, then the body of the post will additionally have the attribute `url` with the download URL as the value.

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -114,8 +114,8 @@ Custom user attributes are not available due to a limitation in Google Tag Manag

```html
<script>
// note: if using SDK version 3.x or below, use `window.appboy` instead of `window.braze`
// version 4 or greater should use `window.braze`
// Note: If using SDK version 3.x or below, use `window.appboy` instead of `window.braze`
// Version 4 or greater should use `window.braze`
window.braze.getUser().setCustomUserAttribute("attribute name", "attribute value");
</script>
```
Expand Down
4 changes: 2 additions & 2 deletions _docs/_developer_guide/platform_wide/analytics_overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -105,14 +105,14 @@ Talk to villagers for essential tips on how to beat levels!
Custom event properties are designed to help you personalize your messaging or build granular action-based delivery campaigns. If you would like to create segments based on event property recency and frequency, reach out to your customer success manager or our Support team, as this may incur additional data costs.

## Custom attributes
Custom attributes are best for storing attributes about your users, or information about low-value actions within your application. You should keep in mind that we don't store time-series information for custom attributes, so you're not going to get any graphs based upon them like the preceding example for custom events.
Custom attributes are extraordinarily flexible tools that allow you to target users with greater specificity than you would with standard attributes. Custom attributes are great for storing brand-specific information about your users. You should keep in mind that we don't store time-series information for custom attributes, so you're not going to get any graphs based on them like the preceding example for custom events.

### Custom attribute storage

All user profile data (custom events, custom attribute, custom data) is stored as long as those profiles are active.

### Custom attribute data types
Custom attributes are extraordinarily flexible tools that allow for great targeting. The following data types may be stored as custom attributes:
The following data types may be stored as custom attributes:

#### Strings (alpha-numeric characters)
String attributes are useful for storing user input, such as a favorite brand, a phone number, or a last search string within your application. String attributes can be up to 256 characters long.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -70,7 +70,7 @@ While we provide an extensive list of resources for customers to reference pre-s
- **Updating copy post-send**: Once a card is sent, you will be unable to update the copy. Instead, you will need to remove the original card and send down a new card with any updates.

#### Things to know
- **Eligible Content Card limits**: There is no limit to display Content Cards to a user, however Braze will not remove older cards from the feeds.
- **Eligible Content Card limits**: There is no limit to display Content Cards to a user. Braze will not remove older cards from the feeds.
- [**Reporting terms**]({{site.baseurl}}/user_guide/message_building_by_channel/content_cards/reporting/): Review terms such as total impressions, unique impressions, and unique recipients as the definitions can sometimes cause confusion.
- **Content Card refresh**: By default, Braze refreshes Content Card requests as they sync at session start, on feed down swipe (mobile), and when the cards view is shown if the last refresh was over one minute ago.
- **Caching Content Cards**: Content Card caching options can be found in our [Android/FireOS]({{site.baseurl}}/developer_guide/platform_integration_guides/android/content_cards/customization/custom_styling/#customizing-card-rendering-for-android) and [Web](https://js.appboycdn.com/web-sdk/latest/doc/modules/appboy.html#getcachedcontentcards) docs.
Expand Down
14 changes: 7 additions & 7 deletions _docs/_help/help_articles/data/dispatch_id.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,29 +9,29 @@ description: "This article covers dispatch ID behavior, including it's usage, im

# Dispatch ID behavior

A `dispatch_id` is the ID of the message dispatch-a unique ID for each "transmission" sent from Braze. Users who are sent a scheduled message get the same `dispatch_id`, while action-based or API-triggered messages will receive a unique `dispatch_id` per user.
A `dispatch_id` is the ID of the message dispatcha unique ID for each "transmission" sent from Braze. Users who are sent a scheduled message get the same `dispatch_id`, while action-based or API-triggered messages will receive a unique `dispatch_id` per user.

{% alert important %}
Note that `dispatch_ids` are per user, per campaign for triggered (action-based or API-triggered) messages.
Note that `dispatch_id`s are per user, per campaign for triggered (action-based or API-triggered) messages.
{% endalert %}

This can result in two different users having different `dispatch_ids` for a single campaign if messages were sent at two different times. This is often because the API requests were made separately. If both users were in the same campaign audience in a single send, their Dispatch IDs would be the same.
This can result in two different users having different `dispatch_id`s for a single campaign if messages were sent at two different times. This is often because the API requests were made separately. If both users were in the same campaign audience in a single send, their `dispatch_id`s would be the same.

## Dispatch ID behavior in campaigns

Scheduled campaign messages get the same `dispatch_id`. Action-based or API-triggered campaign messages will get a unique `dispatch_id` per user. For example, two users in your scheduled campaign audience will have the same `dispatch_id`. However, two users in the audience of an API-triggered campaign will have different `dispatch_ids`.
Scheduled campaign messages get the same `dispatch_id`. Action-based or API-triggered campaign messages will get a unique `dispatch_id` per user. For example, two users in your scheduled campaign audience will have the same `dispatch_id`. However, two users in the audience of an API-triggered campaign will have different `dispatch_id`s.

Multichannel campaigns will have the same behavior as described for their delivery type.

{% alert warning %}
Dispatch IDs are generated randomly for all Canvas Steps because Braze treats Canvas Steps as triggered events, even when they are "scheduled". This may result in inconsistencies generating the ids. Sometimes, a Canvas component will have unique `dispatch_ids` per user per send, or it may have shared `dispatch_ids` across users per send.
A `dispatch_id` is generated randomly for all Canvas Steps because Braze treats Canvas Steps as triggered events, even when they are "scheduled". This may result in inconsistencies generating the IDs. Sometimes, a Canvas component will have unique `dispatch_id`s per user per send, or it may have shared `dispatch_id`s across users per send.
{% endalert %}

## Template dispatch ID into messages with Liquid

If you want to track the dispatch of a message from within the message (in a URL, for example), you can template in the `dispatch_id`. You can find the formatting for this in our list of Supported Personalization Tags, under [Canvas Attributes]({{site.baseurl}}/user_guide/personalization_and_dynamic_content/liquid/supported_personalization_tags/).

This behaves just like `api_id`, in that since the `api_id` isn't available at campaign creation, it is templated in as a placeholder and will preview as `dispatch_id_for_unsent_campaign`. The id is generated before the message is sent, and will be included in as send time.
This behaves just like `api_id`, in that since the `api_id` isn't available at campaign creation, it is templated in as a placeholder and will preview as `dispatch_id_for_unsent_campaign`. The ID is generated before the message is sent, and will be included in as send time.

{% alert warning %}
Liquid templating of `dispatch_id_for_unsent_campaign` does not work with in-app messages, since in-app messages don't have a `dispatch_id`.
Expand All @@ -41,7 +41,7 @@ Liquid templating of `dispatch_id_for_unsent_campaign` does not work with in-app

In the effort to continue enhancing our Currents capabilities, we're adding `dispatch_id` as a field to Currents email events across all connector types.

The `dispatch_id` is the unique id generated for each transmission, or dispatch, sent from the Braze platform.
The `dispatch_id` is the unique ID generated for each transmission, or dispatch, sent from the Braze platform.

While all customers who are sent a scheduled message get the same `dispatch_id`, customers who receive either action-based or API-triggered messages will get a unique `dispatch_id` per message. The `dispatch_id` field enables you to identify which instance of a recurring campaign is responsible for conversion, thus equipping you with more insights and information on which types of campaigns are helping push the needle on your business goals.

Expand Down
Loading