> For the complete documentation index, see [llms.txt](https://docs.coupler.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.coupler.io/sources/category/marketing/bitly/best-practices.md).

# Best Practices

## Recommended setup

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>Start with Bitlink clicks + Bitlinks</strong></td><td>These two entities together give you the most complete picture. Join them on the <code>id</code> field to get click counts alongside the original URL, title, and tags in one table.</td></tr><tr><td><strong>Always set a date range</strong></td><td>Bitly's click API requires start and end dates. Without them, you may get empty results. Use the date pickers to define a consistent window — weekly or monthly ranges work well for recurring reports.</td></tr><tr><td><strong>Use group_guid as your join key</strong></td><td>Most Bitly entities are tied to a group. Keep <code>group_guid</code> in every entity you pull so you can join Group names and preferences to your click or shorten count data later.</td></tr></tbody></table>

## Data refresh and scheduling

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>Match refresh frequency to your reporting cadence</strong></td><td>For weekly campaign reports, a daily refresh is more than enough. For real-time monitoring, keep in mind Bitly's API can lag a few hours behind the dashboard — hourly syncs won't give you truly live data.</td></tr><tr><td><strong>Use Append for historical click data</strong></td><td>Bitly's API returns data for a specific date window each time. Use Coupler.io's Append mode to accumulate click history over time rather than overwriting it — this lets you build a growing dataset without re-pulling old data manually.</td></tr></tbody></table>

## Performance optimization

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>Split large link catalogs by group</strong></td><td>If your organization has thousands of Bitlinks, consider creating separate data flows per group rather than pulling everything at once. This reduces the risk of hitting rate limits and makes it easier to filter data downstream.</td></tr><tr><td><strong>Pull shorten counts separately from click data</strong></td><td>Group shorten counts and organization shorten counts are lightweight endpoints — put them in their own data flow to avoid mixing slow click-data calls with fast metadata calls.</td></tr></tbody></table>

## Common pitfalls

{% hint style="danger" %}
Do not rely on a single Bitlink clicks pull to cover a long historical period all at once. Bitly may throttle or truncate responses for very wide date ranges. Pull data in monthly chunks and use Append to combine them.
{% endhint %}

{% columns %}
{% column %}
**Do**

* Join Bitlinks and Bitlink clicks on `id` for complete link reports
* Use Append mode to build historical click history incrementally
* Keep date ranges tight and consistent across data flows
* Store `group_guid` and `organization_guid` fields for cross-entity joins
  {% endcolumn %}

{% column %}
**Don't**

* Pull Campaigns or Channels on a Free plan — they'll return 403 errors
* Set identical wide date ranges on every entity — only click-based entities need date filtering
* Ignore the `archived` field in Bitlinks — archived links can inflate your link count if you don't filter them out
  {% endcolumn %}
  {% endcolumns %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.coupler.io/sources/category/marketing/bitly/best-practices.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
