I understand your warning regarding Querying with a granularity of PT30M may lead to slow data loading and rate limiting issues. We retrieve bulk data only for initial data loads and on regular basis we pull only past 1week data.
My goal is to store these PT30M segments in UTC and generate adherence reports that can be displayed in multiple time zones by allowing users to select their preferred time zone via checkboxes in Power BI.

I don't know exactly what you are trying to accomplish, but I do have a bit of a warning about the 30 minute granularity approach. Making multiple historical adherence requests, each with a range of only 30 minutes, could quickly run into rate limiting, if the total range of data you require is large. It technically could work but could be very slow to make all the requests.

Thank you @Dan_Hoffman
Currently we are going with your suggestions by using customer specific Timezone instead of UTC. Will revisit this again to support multiple timezones by saving data with Granularity PT30M and UTC Timezone.

So all data is returned in UTC regardless of the time zone parameter. The time zone parameter only changes what is considered the start of the day for the day metrics but it will still be returned in UTC.

Here is how I would recommend using the bulk historical adherence endpoint. You should make sure in the request that all the management units you request have the same time zone configured, and set that as the time zone parameter. Also make sure that the startDate and endDate you provide are set to the start of day for that time zone. For example if I wanted to request yesterday's adherence for two management units in the same business unit, and that business unit was configured for the America/New_York time zone, the request body would look like this:

{
    "timezone": "America/New_York",
    "items": [
        {
            "managementUnitId": "someId",
            "startDate": "2024-11-11T05:00:00Z",
            "endDate":  "2024-11-12T05:00:00Z",
            "includeExceptions": true,
            "includeActuals": true
        },
        {
            "managementUnitId": "someOtherId",
            "startDate": "2024-11-11T05:00:00Z",
            "endDate":  "2024-11-12T05:00:00Z",
            "includeExceptions": true,
            "includeActuals": true
        }
    ]
}

This will return adherence for November 11th for those management units. Since the start of day for the America/New_York timezone for that day is 2024-11-11T05:00:00Z, there will only be a single day metric that is lined up perfectly with the requested date range.

If we aim to support multiple time zones and there isn't a granularity property like PT30M available in the request body, we need to consider how to structure our queries. For instance, if we want to retrieve adherence data for the past day in UTC, should we break the request interval into 30-minute segments?

The formula used to calculate adherence and conformance percentages can be found here: